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
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
