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

[Kevin Kofler]

Giuseppe D'Angelo via Development wrote:
> In other words, the advantages of keeping the Qt equivalents start to be
> (seriously) questioned. We're therefore left with the question of what
> to do with these equivalents.
> 
> * We could play the catch-up game, but that requires a development
> investment that is simply not there any more, and is even questionable
> (is it the job of people developing Qt to rewrite algorithms widely
> available elsewhere?).
> 
> * We could move the Qt equivalents into a "support library", maybe with
> deprecation warnings, maybe without. I'm not sure of the traction of
> this idea these days, but IIRC having "Qt4Support" was frowned upon when
> Qt 5 was being shaped. (Thus QtAlgorithms was left in QtCore, deprecated.)
> 
> * We could just deprecate and tell people to migrate away. That's kind
> of the whole point of this thread, and comes with all the annoyances,
> and people reimplementing them downstream because they still want the
> convenience of a qSort(vector) over std::sort(vector.begin(),
> vector.end()).
> 
> * 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.)

There is one option missing:

* We could just keep the Qt equivalent as is, without adding the features
  of the STL equivalent if there is no manpower to port them to the Qt
  equivalent. Developers using the Qt version are happy with the Qt version
  as is, and those that are not can always go and use the STL. There is no
  point in deprecating or splitting out those classes, they should just
  remain in QtCore where they belong.

> Here's where the "extension" bites us: if the Qt equivalent offered
> something that upstream is not offering, and we can't reimplement it,
> then what do we do? Dropping support for it would be, at best, an API
> break; and at worst, a _silent_ behavioural change.

That's why you should just not do that, and instead keep the Qt 
implementation. Let the users decide for themselves whether they prefer the 
advantages of one (Qt) or the other (STL) implementation.

I, for one, don't give a darn about all those new C++11/14/whatever STL 
features. I don't want to touch the STL with a 10-foot pole! The best thing 
Qt can do with the STL is pretend it doesn't exist. (I wish QT_NO_STL were 
still supported!)

        Kevin Kofler