On Monday, 13 November 2023 09:15:10 PST Marc Mutz via Development wrote: > On 13.11.23 17:15, Thiago Macieira wrote: > > On Monday, 13 November 2023 01:34:08 PST Ivan Solovev via Development wrote: > > I don't think this minor thing is worth the hassle. It uglifies our API > > for > > little gain. > > What, specifically, is ugly? That we have two Qt partial_ordering types?
Yes. > Anyway, that's subjective. Objectively, it breaks the impasse between > full efficiency in future-looking C++20 builds and Qt BC guarantees. We're not losing anything either because the only case where this would be necessary is if we needed to return a std::partial_order result from a non- inline function that is, in turn, calling the non-inline QMetaType and/or QVariant functions. We have zero of those today and aren't likely to get any of them, probably ever. Some user code might, but I find it unlikely too. It could happen if the user decided to wrap a QVariant in a larger type that did have a three-way out-of- line comparison function. Everywhere else, the optimiser will do the right thing. > Given that Qt 7.0 is many years away, I don't think it's too much to ask > to go the extra mile and remove the overhead. We seem to agree how to do > it technically, and it won't be on you to implement all this, but on > Ivan and me. I think I speak for Ivan, too, if I say that we'd rather > today than tomorrow see this stuff merged. The next FF is already > approaching again. It could be done, but I just don't see the value. If we do it, please come up with proper Qt-style class names for it. No snake_case. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development