> On Friday, 5 October 2018 08:35:10 PDT Thiago Macieira wrote: >>> Cons: >>> Suppresses move construction as in >>> QCborValue v = array[n]; >>> this still compiles, but passes through the copy constructor, not >>> the move one. We cana add an extra move constructor for const >>> QCborValue && if necessary.
On 6 Oct 2018, at 00:47, Thiago Macieira <[email protected]> wrote: >> Never mind, you can't move from the const rvalue reference. It needs >> to be modifiable. >> >> So, again: should we have the const in the return types at the >> expense of losing the move semantic? Lars Knoll (7 October 2018 10:53) > I’d go for returning a const object. It’s a shame to loose the move > semantics, but the other case would lead to easy programming errors. The change currently staged for integration [0] only adds const to the QCborValue return types of the read-only operator[] on QCbor{Array,Map}; as noted in the review comments there, there are several other methods returning QCborValue, e.g. at(index) and value(key), that potentially need to also return it as const. My rationale for limiting this to operator[] was that a['b']['c']['d'] = 12 might seem like a reasonable thing to do, while a.at('b')['c']['d'] = 12 seems more obviously like a senseless thing to attempt. [0] https://codereview.qt-project.org/240046 So the question arises: which other QCbor{Map,Array} methods should const-qualify their QCborValue returns ? Eddy. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
