Why not flag away the mistakes of the past?

[Taylor Hillegeist]

On Thursday, 8 March 2018 at 17:14:16 UTC, Jonathan M Davis wrote:
> On Thursday, March 08, 2018 16:34:11 Guillaume Piolat via 
> Digitalmars-d wrote:
>> On Wednesday, 7 March 2018 at 13:24:25 UTC, Jonathan M Davis
>>
>> wrote:
>> > On Wednesday, March 07, 2018 12:53:16 Guillaume Piolat via
>> >
>> > Digitalmars-d wrote:
>> >> On Wednesday, 7 March 2018 at 06:00:30 UTC, Taylor 
>> >> Hillegeist
>> >>
>> >> wrote:
>> >> > That way the breaking change was easily fixable, and the 
>> >> > mistakes of the past not forever. Is it just the cost of 
>> >> > maintenance?
>> >>
>> >> auto-decoding problem was mostly that it couldn't be @nogc 
>> >> since throwing, but with further releases exception 
>> >> throwing will get @nogc. So it's getting fixed.
>> >
>> > I'd actually argue that that's the lesser of the problems 
>> > with auto-decoding. The big problem is that it's 
>> > auto-decoding. Code points are almost always the wrong level 
>> > to be operating at. The programmer needs to be in control of 
>> > whether the code is operating on code units, code points, or 
>> > graphemes, and because of auto-decoding, we have to 
>> > constantly avoid using the range primitives for arrays on 
>> > strings. Tons of range-based code has to special case for 
>> > strings in order to work around auto-decoding. We're 
>> > constantly fighting our own API in order to process strings 
>> > sanely and efficiently.
>>
>> I'd agree with you, hate the special casing. However it seems 
>> to me this has been debated to death already, and that 
>> auto-decoding was successfully advocated by Alexandrescu and 
>> al; surviving the controversy years ago.
>
> Most everyone who debated in favor of it early on is very much 
> against it now (and I'm one of them). Experience and a better

I wasn't so much asking about auto-decoding in particular more 
about the mentality and methods of breaking changes.

In a way any change to the compiler is a breaking change when it 
comes to the configuration.

I for one never expect code to compile on the latest compiler, It 
has to be the same compiler same version for the code base to 
work as expected.

At one point I envisioned every file with a header that states 
the version of the compiler required for that module. A 
sophisticated configuration tool could take and compile each 
module with its respective version and then one could link. (this 
could very well be the worst idea ever)

I'm not saying we should be quick to change... oh noo that would 
be very bad. But after you set in the filth of your decisions 
long and hard and are certian that it is indeed bad there should 
be a plan for action and change. And when it comes to change it 
should be an evolution not a revolution.

It is good avoiding the so easily accepted mentality of legacy... 
Why do you do it that way? "It's because we've always done it 
that way."

The reason I like D is often that driven by its community it 
innovates and renovates into a language that is honestly really 
fun to use. (most of the time)