Please be more careful when changing the language behavior

Panke tobias at pankrath.net
Wed Jun 3 08:11:12 UTC 2020


On Wednesday, 3 June 2020 at 07:56:54 UTC, Walter Bright wrote:
> On 6/2/2020 9:21 PM, mw wrote:
>> In my view, D2 has already been feature rich enough for people 
>> to do their work. What they want most is compiler stability, 
>> not any more new language features. By freezing D2, they will 
>> have a more stable platform to get their work done without 
>> worrying about breakage. And for you, it will buy you more 
>> time, e.g. a few years, to design carefully the next major 
>> features / fixes you want introduce in D3.
>
> We simply don't have the resources to support a fork of the 
> language.

Would be a schema as described here [1] be possible?

In a nutshell each breaking change is introduced with a switch 
named --incompatible_<name> that activates it. The default is to 
be turned off and this is quite similar to what we have with 
-preview=. After some time the default becomes on and you have to 
explicitly disable it, if you want to keep using your old code.

The crucial difference to what we do is: Every breaking change is 
guaranteed to have an migration path that allows you to change 
your code in a way that it works with both 
--incompatible_<name>=on and --incompatible_<name>=off. So you do 
not have to update your complete codebase on every breaking 
change and the recommendation is to never use --incompatible in 
your production setup.


[1] 
https://docs.bazel.build/versions/master/backward-compatibility.html


More information about the Digitalmars-d mailing list