Vision for the D language - stabilizing complexity?

[Andrew Godfrey via Digitalmars-d]

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