[Development] QUIP 6: removing top-level const from return types

Marc Mutz 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 
>> code
>> any more than adding a function overload?
> I thought we were discussing Source Incompatible Changes. If it doesn't 
> break
> 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 mailing list