[Development] Deprecation/removal model going into Qt 6

[Kevin Kofler]

Philippe wrote:

> On Sat, 1 Jun 2019 14:36:12 +0200
> André Pönitz <apoenitz at t-online.de> wrote:
> 
>> So it might make even sense to step back further and start with
>> asking "What should Qt be?" before trying to find out on whether
>> a specific API is poorly designed or not, as that decision depends
>> on the purpose.
> 
> I second a recent quote from Lars Knoll :
> 
>> Qt has always had a somewhat different philosophy. Make C++ easy to use,
>> no need to use Java. The fact is that 95% of the source code our users
>> write will not be performance critical. You don't want to make the pay
>> the price of having a difficult to use API for those 95% of the code.
> 
> And I wish to add: the vast majority of Qt developers I have met, are
> not C++ wizards.

Indeed. One case in point: All this confabulation about move constructors 
etc. misses the point that the gain of moving compared to shallow copying 
with CoW is typically irrelevant for those 95% of non-performance-critical 
code. But using explicit move semantics correctly is significantly harder 
and more prone to misuse than using Qt's implicit CoW.

To avoid a deep copy STL-style, you have to use std::move explicitly. To 
avoid the deep copy Qt-style, you just assign the Qt container and it will 
automatically be just a shallow copy. And the Qt idiom is more flexible 
because it does not force you to invalidate the original reference.

(That said, at least there *is* a way to avoid the deep copy in STL now. In 
C++98, e.g., returning an STL container from a function was just a no-go.)

And yes, I know that there are corner cases where std::move can help on CoW 
types, saving some atomic operations, or even avoiding a detach because the 
old reference was invalidated by std::move. But I still would NOT call 
incomplete implementation of move semantics a showstopper in a CoW data 
structure API (unlike some of the self-proclaimed "C++ wizards" here).

        Kevin Kofler