[Development] unified data model API in QtCore => thin wrapper proposal

[Edward Welbourne]

> 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 <thiago.macieira at intel.com> 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.