[Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Kevin Kofler]

André Pönitz wrote:
> I see that pattern, too. But now, instead putting the break between 3) and
> 4), the whole thing is killed, and everybody downstream has to do 1)-3)
> again, or put up with what the standard offers.
> 
> And could prevent overextension by -x'ing the respective change on gerrit.
> So *that* sounds fixable.

But why should Qt let itself be crippled by the STL's limitations? Qt 
classes being better than STL classes is a GOOD thing.

>> * We could keep things where they are, supported, thus offering the
>> easier APIs; but simply reimplement them on top of the "upstream"
>> equivalents. (Ignore the possible ABI break.)
> 
> The last one is the most reasonable.

It is not, because it means Qt can no longer offer features that make it 
better than the STL.

Instead, the Qt implementation should be kept as is.

>> Long story short, making qSort() call std::sort() might not have kept the
>> behaviour contract with the user.
> 
> *shrug*
> 
> And what if I, as a user, would not care?
> 
> What about https://valdyas.org/fading/hacking/happy-porting/

If you break the contract with the user by silently changing the underlying 
implementation incompatibly, you also force the user to do porting (e.g., 
from qLess to std::less). So the user will care.

QtAlgorithms should just be undeprecated. I don't care whether std::sort is 
faster. If the version of Qt I tested with was fast enough, then I'm 
perfectly fine with newer versions not being faster, no matter how fast some 
incompatible implementation elsewhere is (and I don't care whether it 
happens to ship with my compiler or not).

        Kevin Kofler