[Development] QtCS 2017 QtCore sessions

Marc Mutz marc.mutz at kdab.com
Tue Dec 5 10:22:11 CET 2017


On 2017-12-04 21:05, Ville Voutilainen wrote:
> Same goes for semantics.

In fact, I'm _mainly_ concerned with semantics. Different method naming 
is trivially fixed by tooling these days, as long as the semantics are 
the same.

As a trivial example: qAsConst, like std::as_const, has the rvalue 
overload `= delete`d. For Qt containers, and most STL ones, too, with 
the notable exceptions of QVLA and std::array, it would make sense to 
allow the rvalue overload, but return a new object moved from the 
original. Then lifetime extension would kick in and

   for (auto &e : qAsConst(funReturningQVector()))

would be safe, albeit less efficient as the alternative. But getting rid 
of qAsConst would then be much harder, since std::as_const does not have 
an overload for rvalues, so the above code would need to be transformed 
into

   const auto uniq = funReturningQVector();
   for (auto &e : uniq)

which is what you're forced to write today already, thanks to the lack 
of the rvalue overload.

As an aside: it also makes the API easier to abuse (by allowing 
std::array and QVLA rvalues).

So, IMNSHO, it's better to not add the rvalue overload to qAsConst, but 
keep it `= delete`d, thereby maintaining semantic one-to-one-ness with 
std::as_const, in turn making tools to perform the rewrite trivial (in 
this case, as easy as `s/qAsConst/std::as_const/g`).

Thanks,
Marc




More information about the Development mailing list