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).