Please be more careful when changing the language behavior

[Mathias LANG]

On Tuesday, 2 June 2020 at 05:32:08 UTC, Walter Bright wrote:
> All I can say is you're right, and we handled this badly.
>
> alias this has a lot of problems, mainly because it tries to 
> implement multiple inheritance without thinking it through. 
> I've looked at fixing them, and essentially it is unfixable. 
> We'll just have to live with the way it works, and shouldn't 
> try to modify its behavior again.
>
> Changes to the compiler rely very heavily on the test suite. If 
> cases aren't in the test suite, we don't know when break things.

In this case, the test case *was* in the test suite, or more 
precisely in druntime 
(https://github.com/dlang/druntime/pull/2476). So druntime was 
changed and is was merged without a user-visible message.

That's why I've been advocating to make *any* change that change 
user code's behavior, even if it disallow something that 
shouldn't have been allowed in the first place, to be deprecation 
first. Because of D unparalleled compile-time introspection 
capabilities, there is not a single change you can make to the 
language or any library that *cannot* result in code breakage. 
For example, adding any public function to a library will break 
code relying on the symbol not existing (e.g. 
`!is(typeof(SomeSymbol))`). Now it doesn't mean we should stop 
adding new things or changing / fixing things, but it shouldn't 
be done without consideration for the potential breakage. One 
thing that should be at the very top of the list of "absolutely 
not going to happen" is silently changing which user code is 
executed without notification, and that's what happened here.

Having worked at companies that use D, we *had* to have "sync 
points" where we updated the compiler. From what I saw, Weka is 
doing the exact same thing. This is because experience have 
proved countless times that upstream cannot be trusted not to 
break stuff. I'm glad to say that things have gotten drastically 
better over the year, and I think Buildkite was a major factor in 
this. Nevertheless, it's still at a point where an update is 
rarely a no-op.