Why can't we derive struct's?

[Timon Gehr]

On 21.12.18 05:09, Walter Bright wrote:
> On 12/20/2018 7:21 PM, Timon Gehr wrote:
>> But it's a solved problem. Just make `alias this` exactly like `import`.
> 
> Imports don't have adjuster thunks,

Neither does `alias this`.

> implicit cast issues,

Treat implicit casting with `alias this` like an invocation of an 
imported function.

> slicing,

`alias this` does not have the slicing problem because it can't return 
something that shares the vtable with the original reference but has a 
different layout.

> or empty base optimizations.
With `alias this`, empty base optimization has to be done manually.

> Import lookup in a class is different because 
> of the two-phase nature of it (people complained bitterly about the 
> earlier single phase lookup).
> ...

Why should it be different? It's a "look up names in one of those 
scopes" problem. Same problem, same solution.

> Import lookup doesn't have to conform to the relevant undocumented C++ 
> ABI, either.> (It was about a year of bug reports until I was finally 
> able to match Microsoft C++'s MFC behavior for MI struct layout.)
> ...

Why would multiple `alias this` have to conform to any C++ ABIs?


>    class C : B {
>      B b;
>      alias b this;
>    }
> 
> Now what? (This is not specified in the dlang spec.)

This is a single alias this problem. But checking imports, this should 
give ambiguity errors by default (for both member access and 
implicit/explicit casting) and there should be a way to explicitly 
disambiguate.