Vision for the D language - stabilizing complexity?

[Charles Hixson via Digitalmars-d]

On 07/18/2016 03:37 PM, Walter Bright via Digitalmars-d wrote:
> On 7/18/2016 6:48 AM, Andrew Godfrey wrote:
>> We risk scaring away potential community members, and alienating 
>> existing ones,
>> by the way we say "no" to proposals for breaking changes. We could 
>> improve how
>> we say "no", by having a place to point people to. Potential topics:
>
> Anything we do will risk scaring away people. The only answer is we 
> have to do what is right.
>
>
>> 3) Why we feel that breaking changes risk killing D outright. (I just 
>> don't see
>> it. I wonder if we're confusing "dfixable" breaking changes, with 
>> other more
>> disruptive kinds (such as Tango=>Phobos).)
>
> Because if you thoroughly break a person's code, you put them in a 
> position of rewriting it, and they may not choose to rewrite it in D3. 
> They may choose a more stable language.
>
> I have many older programs in different languages. It's nice if they 
> recompile and work. It's not nice if I have to go figure out how they 
> work again so I can get them to work again.
>
For some changes there could be switches, rather like optimization level 
switches, or those managed by version.  This would allow the compilation 
version to be set based on a compile time variable,  I'm not totally 
sure whether this should be file level or, as with version, block 
level...or selectable.  This would get to be a huge maintenance chore 
after awhile, but it would allow you a few years to deprecate code.

The question is "How important would a change need to be to justify this 
kind of action?", and my guess is that it would need to be pretty important.