On Sunday, 12 October 2014 at 11:24:17 UTC, Joseph Rushton
Wakeling via Digitalmars-d wrote:
On 12/10/14 12:53, Joseph Rushton Wakeling via Digitalmars-d
wrote:
D2 is, for the most part, excellent in this respect, but it
could and should be
even better. Well-managed, well-documented and
well-publicized breaking changes
in support of usability and correctness are desirable, not
something to be avoided.
I should add here -- I recognize the basic problem that faces
any language when you have newcomers (or potential corporate
adopters) downloading the latest compiler, downloading some
codebase of interest to them, and finding that it doesn't build
because of a backwards-incompatible change. Even when that
change was 100% justified, you risk being seen as unstable,
untrustworthy, etc., and many people are not patient enough to
stick around to hear that justification.
I used to think that this was a valid point w.r.t. rejecting
changes. Over the last year of actually trying to get work done
in D, I've changed my tune somewhat:
At this stage, almost every release will break any project that
has a decent sized code-base, *without considering any language
changes or regressions*!
Fixing *any* rejects-valid or accepts-invalid bug can break
peoples code.[1]
Adding a new symbol in phobos can break peoples code.
The only way of getting meaningful stability is to slow down a
lot. If we're going to keep moving fast (even just fixing bugs),
then it is unavoidable that we will break people's code. We can
afford a little more breakage on top of the inevitable (and
undeniably necessary) pile - even for quite minor gains - as long
as they are changes that can be easily managed by project
maintainers.[2]
The only argument that's left is: "I don't mind you breaking my
code by fixing bugs in the implementation, but I do mind when
it's for cleaning/changing the language/phobos". In light of
recent comments from heavyweight users saying "please break my
code in the name of improving the language and libraries", I
don't think it holds much water.
[1] The "code that was already broken" is often dodgy. What
constitutes broken code? There's a lot of very fragile code out
there that is doing it's job just fine, in the limited
circumstances it's used.
[2] By easily managed I don't mean sed-able, or even
tooling-fixable. For me it pivots on being able to maintain one
code-base that will compile with multiple compiler versions. An
example where this fails: @nogc, being an attribute, isn't
aliasable, meaning you can't version it out neatly.
#PleaseBreakMyCode but also
#PleaseProvideScalableMeansForMeToProvideBackwardsCompatabilityToMyUsersWhoBuildMyCodeOnAVarietyOfSystemsWithAVarietyOfCompilers
Hmm, not so catchy :)
