On Tuesday, 13 June 2017 at 12:23:19 UTC, ketmar wrote:
Sebastien Alaiwan wrote:
My point precisely was that "not splitting D1/D2" might
correspond to "doing things right".
"not splitting" here means "we're stuck with D1". deprecation
cycle of several years (not counting the time required to
actually *start* the process) means "no evolution".
i must make myself clear here, i guess: i value "good language"
way more than "stable language". i absolutely don't mind fixing
my code if it makes it better/more clear/etc. while it's hard
to sell "constantly evolving" language to Big Enterprise
Wheels, not making breaking changes means cloning worst C++
feature. ;-)
Companies clearly value C++'s backwards compatibility. However,
if there's one lesson from the D1/D2 or the Python 2/Python 3
split, it's that it's hugely disruptive (so much so that I find
the idea of D3, at the moment, to be such an obviously terrible
idea that I really wanted to avoid commenting on this thread).
Nevertheless, C++ is still a constantly evolving language. C++14
looks a lot different from C++98. Maintaining backwards
compatibility, however, has significantly increased the
complexity.
Thus, I think there's a trade-off. Breaking changes that improve
the language may be good in certain circumstances, but
Walter/Andrei should try to get the buy-in from big D users
beforehand (even with a depreciation cycle). Requiring some kind
of broad support from big D users would mean that breaking
changes only happen if the the costs of breaking changes are
smaller than the improvement to the language.
