Please be more careful when changing the language behavior

[mw]

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.

I've read industry users complaining about unstable compiler 
breaking their existing code base in the past forum threads. I 
think we need to take this seriously, otherwise D's community 
will shrink over time.

For the two issues you mentioned:

1) If we do not want to separate two compiler versions 
(production 2.x vs development 3.x), then we better add some 
client code base to the current compiler test suite:

E.g. https://code.dlang.org/ has total 1808 packages. Given some 
packages are no longer maintained, let's add the top 500 (or 
1000) most recently updated packages to the compiler test suite: 
make sure at least these top 500 can be compiled (weak 
guarantee), and their `dub test` all pass (strong guarantee), 
before making new compiler releases.


2) for the multiple inheritance problem you try to solve, it 
actually is solvable: as far as I know, only Eiffel language 
solved the diamond inheritance problem gracefully, with keywords 
`rename`, `export`, `undefine`, `redefine` and `select`. Simply 
put: by default the Eiffel compiler will join the features and 
only keep one copy, but allow the user *explicitly* using these 
keywords to define the correct behavior that the user want. (I 
mailed you a copy of Eiffel language manual many years ago at 
pre-D1-age, esp. about multiple inheritance. Maybe you still 
remember? :-)

Here are some online material on Eiffel's multiple inheritance 
solution:

https://en.wikipedia.org/wiki/Multiple_inheritance

"""
In Eiffel, the ancestors' features are chosen explicitly with 
select and rename directives. This allows the features of the 
base class to be shared between its descendants or to give each 
of them a separate copy of the base class. Eiffel allows explicit 
joining or separation of features inherited from ancestor 
classes. Eiffel will automatically join features together, if 
they have the same name and implementation. The class writer has 
the option to rename the inherited features to separate them. 
Multiple inheritance is a frequent occurrence in Eiffel 
development; most of the effective classes in the widely used 
EiffelBase library of data structures and algorithms, for 
example, have two or more parents.[7]
"""

more detail here:
https://www.eiffel.org/doc/eiffel/ET-_Inheritance