[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