[Dlang-internal] Regression control & breaking changes policies

[Walter Bright via Dlang-internal]

On 12/6/2016 5:54 PM, Dicebot wrote:
> On 12/05/2016 03:10 AM, Walter Bright wrote:
>> The table makes sense and looks right. But there's a problem with the
>> return scope changes. It's just too much to just wholesale deprecate
>> things all at once.
>
> It will need to happen at some point anyway. Without having those
> deprecation implemented we can't even know how much existing code is
> affected.

That's the point of the flag. It can be done on the user's timescale, not ours.


>> People need time to ease into it, not be faced with
>> a pile of diverse deprecation messages.
>
> We can introduce `-preview=XXX` flag for that purpose but the key thing
> is that it still has to use deprecations and not errors for all scope
> related changes. Otherwise you introduce dangerous disparity between
> what gets previewed and what will eventually become the default.

I agree, but it doesn't have to be deprecations until the flag becomes the default.


>> Having -transition=safe makes that practical, and also ensures time to
>> correct any unrecognized issues with it.
>
> 1) `-transition` flag is not for this purpose. You want this behavior -
> please introduce new flag group, for example `-preview=scope`. Desire is
> legit but you have to use a different flag for such purpose.

It originally was just `-safe`, but I got a lot of flak for that and pressure to 
use `-transition`. I don't really care what the flag is. It just needs a flag.

I doubt users will really care either if it is -safe, -dip1000, 
-transition=safe, or -preview=safe.


> 2) You must not use the very same flag for bug fixes as an excuse to not
> bother of deprecations. https://github.com/dlang/dmd/pull/6290 is the
> last one remaining now there was no justification to merge it in first
> place.

There isn't a hard line between what is a bug and what is not. It'd be nice if 
there was. Pretty much all of these fall under fixing unsafe code.