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

[Konstantin Tokarev]

09.06.2019, 01:26, "Konstantin Tokarev" <annulen at yandex.ru>:
> 09.06.2019, 01:02, "Kevin Kofler" <kevin.kofler at chello.at>:
>>  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!)
>
> Do you really wish to touch C++ with a ten foot pole? It's such a horrible,
> inconsistent, and complicated language! There are many higher-level languages
> on market which can make you more productive, and you surely won't need to use
> STL. Ever.

Oh sorry, I've forgotten to add a reference:

[1] https://yosefk.com/c++fqa/

-- 
Regards,
Konstantin