[Development] Deprecation/removal model going into Qt 6

[Kevin Kofler]

Giuseppe D'Angelo via Development wrote:
> Also, please name me 3 GUI frameworks that have not broken APIs for 30
> years.
> 
> Also also, please name me 3 libraries that have not broken APIs for the
> 30 years.

There is at least one (almost): Win32 has now existed for 26 years without 
an ABI break.

That said, it is painful to use (directly), proprietary, and not portable. 
But we have to admit that they did really well at maintaining compatibility.

> Also also also, at least in the x86-64 world, major "API breaks" at the
> assembly level have already somehow occurred. And that's an architecture
> that has been around for less than 20 years.

Have they really? Software built for the first x86_64 CPUs still runs 
unchanged, doesn't it?

>> Qt has also become larger and larger over time (despite the removal of
>> APIs considered obsolete).
> 
> The removal of APIs in Qt 5 lifetime has been mostly "limited" to
> dropping entire obsolete modules. No cleanup has been done to deprecated
> API inside a module.

I was comparing the size of Qt 3 and Qt 5. There have been 2 such cleanups 
between them: Qt 4.0 and Qt 5.0. Still, Qt 4 was much larger than Qt 3, and 
Qt 5 is much larger than Qt 4 was.

> Qt 6 wants to do that, and the point of this thread is how to minimize the
> pain.

And my point is that the only way to minimize the pain is to just not do 
that to begin with.

There needs to be a point where a library just stops doing new incompatible 
major releases. See how glibc has now been at glibc 2 (libc.so.6) for 22 
years.

> The intended _scriptable_ solution is
> 
> 1) copy and paste Q_FOREACH from qglobal.h into a central header of your
> project
> 2) rename all occurrences it to MY_FOREACH
> 3) done

That (telling the users to just copy&paste the code from the library) 
defeats the whole point of a software library.

> This is just *false*. You're (deliberately?) ignoring the cost of memory
> allocations and deallocations, hiding them in big-O constants, something
> I already warned you about. I won't then waste time debunking this.

If you have a list of 1000000 800-byte objects and you want to insert an 
element in the middle of the list, with a reasonable malloc implementation, 
the ONE allocation together with the 4 MB memmove for QList::insert will be 
negligible compared to the 400 MB (!) memmove for QVector::insert.

>> Of course, that doesn't imply that it is not possible to do better, in
>> theory. But is this optimization [SSO] worth the trouble of breaking the
>> ABI?
> 
> Yes.

And that's what I doubt, and you have not stated any arguments for your 
claim.

> CoW and SSO are orthogonal optimizations. folly's fbstring has *both*.

They are not entirely orthogonal because CoW only works on strings too large 
for SSO. SSO strings are always deep-copied by design.

        Kevin Kofler