[Development] Deprecation/removal model going into Qt 6

[Giuseppe D'Angelo]

Il 03/06/19 00:08, Kevin Kofler ha scritto:
>> Ballast (obsolete functionality, for various degree of "obsolete") has
>> to be dropped from time to time, causing API breaks. The question in
>> this thread is how to manage those API breaks to be as painless as
>> possible.
> 
> What you call "obsolete functionality" is functionality that existing code
> relies on and rightfully expects to remain there.

Rightfully? By what right exactly?


> I'd rather get fewer (or even no) new features than losing existing ones.

How is this even an argument? Qt will need to evolve and acquire 
features to remain competitive. Again, development bandwidth is finite: 
either the overall quality decreases or some things have to get dropped.


> See also Boudewijn Rempt's blog post on the subject:
> https://valdyas.org/fading/hacking/happy-porting/

I agree with the principle (API breaks are painful), but I strongly 
disagree with the idea that no API breaks can ever possibly happen. And 
the specific example is a terrible one to make a point as the resulting 
API break is trivial to work around (I defined such breakages "scriptable").


>>> Changes such as deprecating or incompatibly rewriting a data
>>> structure as central as QList (as seems to be already consensus for Qt 6)
>>> are just a major disservice to developers.
>>
>> ... exactly, because it's an API break. How can we minimize the damage?
> 
> By simply not doing this change, not now, not ever.
> 
> An array of pointers is the most efficient data structure in practice
> (operations are at most O(n)), dropping it in favor of an O(mn) data
> structure (where m = sizeof(T)) such as QVector is a pessimization. And
> QList also has the prepend optimization that makes most prepends even O(1)
> rather than O(n). I don't see why almost everybody hates it.

As written, the above makes no sense, as it looks like you're comparing 
apples and oranges: time complexities against space complexities.

The fact is: once one removes the big-O factors and deals with actual 
numbers and real world hardware, QVector becomes much better than QList 
as a _general purpose_ sequential container. Emphasis on the general 
purpose, please.

Hence, we want Qt to move away from QList (and encourage users to do the 
same). The point of this thread, once more, was asking how to do that as 
painlessly as possible.



> 
>>> ABI breaks such as the QString
>>> SSO (that also seems to be already consensus for Qt 6) are also
>>> unnecessary and probably also counterproductive in some use cases.
>>
>> What? Why?
> 
> For the "unnecessary" part, because Qt has been working fine without QString
> SSO for years. 

Nice try: https://en.wikipedia.org/wiki/Appeal_to_tradition


> Whether it is actually a performance win or not is irrelevant
> because code manipulating QString is almost never performance-critical. (The
> bottleneck is typically the user.)

"Almost never" is simply wrong (or: [citation needed]).

First and foremost, it's wrong because containers and core classes in 
general are the ones MORE likely to be used in performance critical 
scenarios.

Second, string classes in all major C++ libraries and frameworks are 
deploying SSO *because* it is a performance win.

Third, in a library, *every codepath* is a bottleneck for some user, so 
the library must to be as efficient as possible everywhere.


> For the "probably also counterproductive" part:
> * Because there are surely architectures or environments where copying 256
>    bytes (or whatever the SSO max length actually is) 

This is a straw man argument, specifically an exaggeration.

At some QtCS Thiago was talking about 23-24 QChars, i.e. 48 bytes, plus 
a couple of pointers or so, to bring it to 64 bytes (~ a cacheline).


> * Because the total memory use for an array of QString will likely be
>    higher, due to the padding (space reserved for SSO)?

... or much, much, much lower because you don't have to allocate every 
string's payload separately.


> * Because it means a QString will no longer fit in a pointer slot, which
>    breaks the QList optimization and is the main reason why people want to
>    get rid of QList as we know it now?
QString with SSO will make Qt5List<QString> work in array-of-pointers 
mode, instead of pure vector mode, yes. But the decision of moving away 
from QList had very little to do with this particular point. And we 
already had our share of this: QList<QImage>, QList<QSharedPointer>, 
QList<QVariant>, and so on, see the other email.


***ANYHOW***:

This thread was about managing API breaks. Adding SSO to QString is not 
meant to be an API break (*). Please stop derailing the thread.


(*) Emphasis on _meant_, because obviously it yields observable side 
effects.

Thanks,
-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190603/cc7883c3/attachment.bin>