[Development] How qAsConst and qExchange lead to qNN

[Volker Hilsheimer]

> On 16 Nov 2022, at 09:54, Marc Mutz via Development <development at qt-project.org> wrote:

[…]

>>> But UTF-16 is sacrosanct in Qt. It's a cult. Irregardless of how many
>>> deep copies it takes to convert to and from UTF-16 from native
>>> encodings, people still worship it as god-given. It's not.


[…]

> If CoW is sooooo superior, why did we kick out the industry-standard 
> unsharable state? Because otherwise the performance sucked. Well, CoW 
> performance sucks. Esp. for small strings, which are the majority of 
> strings. Folly uses CoW only for strings > 256 chars, IIRC. But CoW in 
> Qt is another cult, so we rather break correctness of our APIs than back 
> off the cult.
> 
> It saddens me to see the project so stuck in the 90s.



Hi Marc,


I respect and admire your passion for this topic, and your desire to make Qt better on this front. From watching several of your Meeting C++ talks, I know that you strongly believe that this - owning containers, CoW - is a make-or-break topic for the future of Qt. And you put energy into this discussion because you want Qt to succeed also in a C++20 world, where people have perhaps adapted, and expect to be able to use, a programming style where perhaps everything is a stream or asynchronous and awaitable.

But your recent use of divisive language does nothing to further your cause. Many of us are evidently not convinced that this is critical for the success of Qt, because what we experience every day when using Qt, or when looking at user feedback, is that other things are more important. And with that perspective, it’s hard to see how the cost of moving to non-owning interfaces is justified by the benefits.

The cost comes in many forms, and is very tangible: making the change, dealing with the code churn, adapting to the new style, living with inconsistency across a large 3rd party eco system of libraries; and last but not least cost of opportunity and delay for other things we could spend our time on instead. On top of all that, some of our historical attempts in the project have made people weary of changes in the Core.

And as a whole, we have not bought into the benefits of NOI for a real software system, or for the Qt API as a whole. Again, historical changes that were made with the promise of improvements have not always delivered, and often resulted in having to deal with a lot of code changes just to end up with something that performs worse. And if a costly change to Qt addresses none of the problems that users bring to us every day, then we should probably not spend time on it. We try to get more people over to Qt 6, in a very compelling competitive landscape with new languages, game engines, and cross-platform UI technology. The last thing we need right now is more deprecations and changes that people have to constantly chase after. So, if people don't want to change things, then it’s not because they are addicted to a cult or idiom, and I expect that you try to respect their perspective as well.

Yes, this comes with the risk that we are focusing too much on the short term. But even when looking further ahead, large scale changes to a complex systems are almost never a good idea. Qt is a complex system, and we can’t predict the impact of large scale changes. But do we have to?

I don’t see anyone claiming that Qt is flawless, that our current tools (including CoW) are perfect for all situations, and that we can’t or shouldn't make improvements in those places where the status quo is bad enough. Most people participating in this conversation agree that we should make respective additions to Qt, where appropriate. Can we start with that? You proposed that we add a QSpan that is only used internally until at least Qt 6.6; I assume that you had some internal use cases in mind where we can see how this would be used, discuss a real implementation, evaluate the (change of) complexity for users and for implementors, and see what we learn from that.

I asked earlier: what has been the impact of the QObject::setObjectName change for a real application (one that uses .ui files will have a lot of those calls)? It’s one of the (few) APIs in Qt that is always called with a string literal. Did anyone notice anything breaking, or did it cause any porting effort? It seems like a very sensible change to me (which doesn’t mean that I believe that e.g. QLineEdit::setText needs be changed as a logical next step). But perhaps it’s also evidence that it’s a good idea to make that kind of change in selected places (like fromString factory functions).

Volker