Re: [Development] 6.7 FF vs. C++20 comparisons
> On 17 Dec 2023, at 14:16, Marc Mutz via Development > wrote: > > On 16.12.23 10:20, apoenitz wrote: >> Recently there were two serious regression on the Qt side due to "just using >> string views" (which would also be formally permitted), and I've seen now a >> patch that changes a map to a hash to avoid part of the porting "work" to the >> new comparison scheme that makes that change not quite "mechanical". > > Sorry, I am not aware of either, and the lack of specificity in the > above makes it impossible to respond in a meaningful way, so I won't try to. > > Thanks, > Marc Without any more details, let’s continue with the work as scoped for Qt 6.7, e.g. continue rollout to string and smart pointer types, as well as to QModelIndex/QPeristentModelIndex. We need confidence that the framework supports plausible scenarios and learn how to deal with the corner cases, which is better done sooner rather than later. Volker -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] 6.7 FF vs. C++20 comparisons
On Sat, 16 Dec 2023 at 13:22, apoenitz wrote: > > On Fri, Dec 15, 2023 at 05:40:28AM +, Marc Mutz via Development wrote: > > On 13.12.23 18:36, Thiago Macieira wrote: > > > So, +1 for me on going ahead. > > > > Thanks! > > > > Is anyone else here for/against? > > To me this doesn't look like a new feature, so I don't see the feature freeze > blocking this formally. I don't see how it's not a new feature. "Convert more classes to opt in to C++20 three-way comparison" reads like a new feature to me for every word of it. > Maybe I am just generally lacking a certain sense of urgency here to have > this kind of changes, but I think it would be better to avoid the risk by > simply not doing it. I don't understand why it needs to be rushed into 6.7, instead of doing it without such rush for 6.8. Thus my take on this is -1. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] 6.7 FF vs. C++20 comparisons
On 16.12.23 10:20, apoenitz wrote: > Recently there were two serious regression on the Qt side due to "just using > string views" (which would also be formally permitted), and I've seen now a > patch that changes a map to a hash to avoid part of the porting "work" to the > new comparison scheme that makes that change not quite "mechanical". Sorry, I am not aware of either, and the lack of specificity in the above makes it impossible to respond in a meaningful way, so I won't try to. 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
Re: [Development] 6.7 FF vs. C++20 comparisons
On Fri, Dec 15, 2023 at 05:40:28AM +, Marc Mutz via Development wrote: > On 13.12.23 18:36, Thiago Macieira wrote: > > So, +1 for me on going ahead. > > Thanks! > > Is anyone else here for/against? To me this doesn't look like a new feature, so I don't see the feature freeze blocking this formally. But there is also no rule that everything that is formally permitted /has/ to be done. The time after the feature freeze is also useful to get some field testing by the few early adopters, and providing an effectly moving target there does not really help the cause. Recently there were two serious regression on the Qt side due to "just using string views" (which would also be formally permitted), and I've seen now a patch that changes a map to a hash to avoid part of the porting "work" to the new comparison scheme that makes that change not quite "mechanical". So, sure, in a perfect world, this kind of activity would be neutral, but apparently it is possible to fumble. Maybe I am just generally lacking a certain sense of urgency here to have this kind of changes, but I think it would be better to avoid the risk by simply not doing it. Andre' -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] 6.7 FF vs. C++20 comparisons
Il 13/12/23 18:36, Thiago Macieira ha scritto: 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. I'm also +1 on the same grounds. I'm very mildly concerned about "breaks something", not in the sense that a rewrite of the operators using the new facilities will not work, but that it might have semantic changes that will break BC (e.g. for inline code). It was quite hard to spot it on QModelIndex... Thank you, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - Trusted Software Excellence smime.p7s Description: Firma crittografica S/MIME -- 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 18:36, Thiago Macieira wrote: > So, +1 for me on going ahead. Thanks! Is anyone else here for/against? -- 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
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
