[Development] How qAsConst and qExchange lead to qNN

[A. Pönitz]

On Tue, Nov 15, 2022 at 08:07:50AM +0000, Marc Mutz via Development wrote:
> On 14.11.22 23:04, A. Pönitz wrote:
> >> Marc’s proposal of a Non-Owning Interface is already
> >> become manifest in QRegion::begin/end
> >>
> >> https://doc.qt.io/qt-6/qregion.html#begin
> >>
> >> allowing us to write
> >>
> >>
> >> for (auto rect : region) doSomethingWith(rect);
> > Yes, and that's fine [but not quite matching the rest of the discussion
> > of using spans?]
> > 
> >> (while QRegion::rects will have to create a QList even if there is
> >> only a single rect in the inline storage, which is then not a QList).
> >>
> >> This is a*good*  addition to Qt. I think we can make more such
> >> additions to Qt, in places where it makes a real difference for
> >> today’s client code using owning containers, and without changing the
> >> world.
> > Fine with me.
> > 
> > With emphasis on "addition" and "real", and notable absense of "change"
> > and "removal"...
> 
> QVector<QRect> QRegion::rects() const _was_ removed for Qt 6.0.

I was referring to the introduction of begin() and end().

The removal of QVector<QRect> QRegion::rects() const was not needed,
but did not particular hurt.
 
> The trick to treat QRegion as a container of QRect, simplifying both 
> users and implementation of QRegion (no more vectorize()), only worked 
> because QRegion is home to only one collection. It's also a trick you 
> need to see to be able to use it,

I don't think so.

> so discoverability is poor. In the 
> general case, a given class may have more than one collection of items.
> E.g. if circular windows became the new rage, QRegion could be a 
> collection not just of rects, but also of ellipses. Then what?
> 
> Enter span-retuning getters:
> 
>     for (QRect rect : region.rects())
>       ~~~
>     for (QEllipse ell : recion.ellipses())
>       ~~~

Or return per-type proxy-objects implementing begin() and end().

> [..]
> There's a logical incompatibility between "QRegion as a QRect container 
> = good" and "QRection::rects() returning a span of QRect = bad".
> 
> Either both are good ideas or neither are.

No. The idea is that QRegion can be anything it want to /internally/,
but there's a way to consider is as a container of QRects.

> They both grant the same freedoms and put the same constraints on the
> implementation of QRegion, but one is more flexible than the other.

Returning a span requires a container somewhere /and/ adds the implicit
requirement to the lifetime of this storage. It is putting /more/
constraints on the implementation of QRegion.

The container-returning one is more flexible as this can be either
a container that's part of the structure, or be created on-the-fly.

Andre'