[Development] How qAsConst and qExchange lead to qNN

[Marc Mutz]

On 14.11.22 18:11, Thiago Macieira wrote:
> On Monday, 14 November 2022 08:22:44 PST Marc Mutz via Development wrote:
>> Can we agree that NOI for setters is a no-brainer? Then 90% of the
>> usefulness of NOI can already be reaped, in a BC and SC manner. There's
>> pretty little we can do with return values before Qt 7, except use the
>> stuff in private APIs to try it out. But we can and should convert
>> setters already.
> 
> Not without conditions.
> 
> I can agree with that so long as it doesn't remove the ability to add the
> owning equivalent as overload, even if it is a Q_WEAK_OVERLOAD, where it
> benefits because the target code is going to store anyway.

_If_ and for as long as the class stores the data in _that_ owning 
container, fine by me. That'll probably be the case for Qt 6 going 
forward, because of those pesky owning container return types.

That said, I repeat that the goal here needs to be to let each class 
choose its own optimal data structure, and for a large class of cases 
that would be QVLA/llvm::SmallVector, iow: _something_ with a small 
buffer optimisation.

As long as we have an implicitly-shared everywhere policy, it's CoW on 
top of CoW on top of CoW. If the QRegionData/Private is ref-counted, 
then it makes little sense to contain the QRects in a container that's 
_also_ CoW. Nothing is using the implict sharedness of the QRect 
container (rects() is gone in 6.0, and can be re-used for a QSpan<const 
QRect> getter).

> I don't think we will ever change return types.

Your short interjections would be more valuable if you didn't just state 
an opinion, but also give rationale ;-)

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at qt.io>
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io

Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B