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

[Marc Mutz]

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.

Thanks,
Marc