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
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
