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
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
