[Development] Deprecation/removal model going into Qt 6
kevin.kofler at chello.at
Mon Jun 3 00:08:12 CEST 2019
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
> 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
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:
>> 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.)
More information about the Development