Re: [Development] 6.7 FF vs. C++20 comparisons
On Wednesday, 13 December 2023 08:46:57 -03 Marc Mutz via Development wrote: > The question I have, therefore, is the following: is converting more > classes to the new framework considered a feature as in "affected by FF"? I'd say simple changes should be fine. There should be no behaviour change at all, anywhere. If that turns out to be a large change, we may want to postpone; if it breaks something, then we've likely found a bug. So, +1 for me on going ahead. -- 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
Re: [Development] 6.7 FF vs. C++20 comparisons
On 13.12.23 12:46, Marc Mutz via Development wrote: > The counter-argument is that this doesn't change much because the C++ > standard knows an operation called Was interrupted when writing this, then forgot to end the sentence before sending :) Sorry... ... https://eel.is/c++draft/class.spaceship#def:three-way_comparison,synthesized, which can, in certain cases, build a missing op<=> from op< and op==. So, in many cases (TODO: which), the set of user-accessible operations isn't actually changed, relegating this to a pure doc and impl cleanuo / code de-pessimisation. Thanks, Marcq -- Marc Mutz 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 -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] 6.7 FF vs. C++20 comparisons
Hi, TL;DR: is the conversion of a class to the new comparison helper a "feature"? So, the framework, incl. the necessary qdoc command and some ports of classes (QDate/Time) have made it into 6.7 last week, but the current state of the code excludes some helper functions necessary for product types (compareThreeWayMulti) and pointers (Private::total), as well as the actual qdoc macros we want to use for documentation (\equality-comparable, \partially_ordered_with, ...). We also have not managed to roll this out over more classes. The helpers are private API at this point, to not subject to FF, but they're used to convert more classes to the new framework. The question I have, therefore, is the following: is converting more classes to the new framework considered a feature as in "affected by FF"? The argument for is that classes (at least ordered ones) then gain the <=> operator in C++20 builds. The counter-argument is that this doesn't change much because the C++ standard knows an operation called If so, I'd like to request a FF-exception to continue the rollout to at least all string and smart pointer types and the already-up-for-review QModelIndex/QPersistentModelIndex. Without this, it's hard to prove out the framework actually works in all cases. Thanks, Marc -- Marc Mutz 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 -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
