[Development] Deprecation/removal model going into Qt 6

[Kevin Kofler]

Giuseppe D'Angelo via Development wrote:

> Il 01/06/19 23:34, Kevin Kofler ha scritto:
>> But the problem for developers is NOT the 5.x releases that do not break
>> the API. Those are great! The problem is those n.0 releases that DO break
>> the API. And the solution there would be to just stop doing this kind of
>> releases.
> 
> But this is simply impossible. It would require an infinite development
> bandwidth, and at a certain point, may constrain development too much.

There is a finite amount of code, so the required development bandwidth is 
also finite. :-)

> 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.

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

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

>> 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.

>> 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. 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.)

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) is more expensive than
  copying a 4-to-8-byte pointer and incrementing an atomic reference count?
  SSO bypasses CoW and forces you to copy the whole string by value. This
  may be a win on current x86 architectures where atomics are really
  expensive, but it is surely not universally true.
* Because the total memory use for an array of QString will likely be
  higher, due to the padding (space reserved for SSO)?
* 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?

>> Your proposal to break ABI at every 6.x minor release would be an
>> absolute nightmare for distributors.
> 
> I personally interpreted "continuous flow of carefully managed changes"
> as "small" API breaks, not (just) ABI breaks.

Breaking API automatically also breaks ABI, so it is worse. Distributors 
would still have to deal with all the ABI breakage nightmare, but in 
addition, API changes may require patches to the software to be able to 
rebuild it against the new ABI. And if your API change is actually a 
removal, the software might not be easily patchable at all and distributors 
might be forced to ship yet another Qt compatibility library forever. (We 
are already stuck with Qt 3, 4, and soon 5 as compatibility libraries.)

        Kevin Kofler