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