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