[Development] QUIP 6: removing top-level const from return types
marc.mutz at kdab.com
Tue May 23 20:22:46 CEST 2017
On 2017-05-23 16:17, Thiago Macieira wrote:
> On Monday, 22 May 2017 22:26:38 PDT Marc Mutz wrote:
>> > if there's a chance of existing code breaking
>> How can removing top-level const from a return type "break" existing
>> any more than adding a function overload?
> I thought we were discussing Source Incompatible Changes. If it doesn't
> anything, it isn't SIC.
So you still didn't read the QUIP?
https://quips-qt-io.herokuapp.com/quip-0006.html (warning: outdated,
which means I have no clue where the current one is supposed to be,
except in Git).
Every change can break existing code. One bug-fix breaks the
work-around, the other fixes behaviour that people unrightfully depended
on (see https://bugreports.qt.io/browse/QTBUG-60914 as the latest
example). Adding a function overload breaks taking the function's
address. Adding a function template overloading a function breaks it in
such a way as to make it impossible (afaics) to take the address of the
non-template function (QTimer::setInterval vs. qOverload issue).
Removing an unnecessary #include breaks TUs that incorrectly depended on
this indirect include. And removing the const of a return value breaks
code that tries to store the function into a pointer-to-function with
the old signature. So they are all SiC.
The point is that these are all qualitatively different from, say,
incompatibly changing (or removing) an inline, non-exported, public
function, which is BC, but SiC. This division into the two qualities of
SiCs (acceptable and not) is what QUIP-6 is all about.
These are acceptable because they affect only more-or-less broken code.
And since they are acceptable, we ought to be able to perform them
freely, without a discussion every time. We don't discuss adding
function overloads. We weren't even aware that there's an issue. We used
to discuss removing unneeded #includes or adding explicit to ctors, both
of which used to be effectively banned, until the discussion leading to
QUIP-6 culminated in the decision that these are acceptable.
Unfortunately, this thread slowly eats away all the productivity gain we
have enjoyed due to reduced debates since then.
More information about the Development