Why can't we derive struct's?

[Quotes Update]

On Friday, 21 December 2018 at 13:48:56 UTC, Timon Gehr wrote:
> 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.
https://quotesupdate.com/funny-whatsapp-status.html