On Tuesday, 19 July 2016 at 09:49:50 UTC, Chris wrote:
On Monday, 18 July 2016 at 18:03:49 UTC, Mathias Lang wrote:
2016-07-18 15:48 GMT+02:00 Andrew Godfrey via Digitalmars-d < digitalmars-d@puremagic.com>:




I've never seen a definitive "No" to breaking changes.
We do breaking changes all the time. Did everyone already forget what the latest release (2.071.0) was about ? Revamping the import system, one of
the core component of the language.
But it took a lot of time, and experience, to do it. It did deprecate patterns people were using for a long time before (e.g. inheriting imports), but its a (almost) consistent and principled implementation.

Although it can be a PITA, people accept breaking changes, if they really make sense.

Way too often I see suggestions for a change with one (or more) of the
following mistakes:
- Want to bring a specific construct in the language rather than achieve a
goal
- Only consider the pros of such a proposal and completely skip any cons
analysis
- Focus on one single change without considering how it could affect the
whole language

That's also my impression. Given that D is open source I'm surprised that nobody has grabbed it and come up with a prototype of D3 or whatever. How else could you prove your case? After all the onus of proof is on the one who proposes a change. Don't just sit and wait until Walter says "Go ahead", knowing full well that the core devs are in no position to dedicate time to D3 at the moment - that's too easy and it gets us nowhere.

But I've never seen someone willing to put the effort in a proposal to
improve the language be turned away.
In fact, our review process for language change was recently updated as well to make it more accessible and save everyone's time. If it's not a commitment for continuous improvement of the language, I don't know what it
is.

We all seem to be in agreement that people often make breaking-change proposals without considering the impact properly. I have seen this many times on the forums and not once (so far) has the reply been simply, "please go and read the section of our vision doc that talks about breaking changes".

I'm suggesting that is what should happen. Instead, I have seen each time a disussion thread that explores only parts of the topic of breaking changes, and does so badly. Just like earlier in this thread, where I mentined dfixable breaking changes and Walter implied that even though a would cause people to have to manually rewrite.

(This example is a specific bias I have noticed in other threads: arguing about a breaking change without evaluating whether it is dfixable).

Reply via email to