Why can't we derive struct's?

[Walter Bright]

On 12/21/2018 5:48 AM, 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`.

That depends on how it is specified. For example, should functions found through 
'alias this' go into the vtbl[]? (It's not a vacuous question, it has come up 
with people wanting that to happen. I said no.)


>> implicit cast issues,
> Treat implicit casting with `alias this` like an invocation of an imported 
> function.

It's not that simple. There are issues with what is considered a "better" match, 
several of which are in bugzilla w.r.t. alias this.


>> 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.

That all depends on how one defines how alias this lookup works wrt providing 
functions to be installed in the vtbl[].


>> 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.

That isn't how import lookup works today when import declarations appear in 
classes. It originally worked that way, but nobody understood it. I was UNABLE 
to explain that import lookup worked exactly like member lookup. I even showed 
the code which was the same code. But everyone, simply could not understand this 
and insisted it was behaving bizarrely. So now it is a much more complex 2 phase 
lookup that behaves "intuitively". It's a great lesson in how "obvious" and 
"intuitive" behavior for a person is anything but as an algorithm.


>> 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?

Because people can, will, and do (see Manu) use it to try to emulate struct 
inheritance for C++ structs.


>>    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.

That isn't how imports work (the base class lookup takes precedence over import 
lookup).

To sum up, the behavior of single alias this is not spec'ed, and there are a lot 
of decisions to make to tighten that up that are not obvious. All that would 
have to be done before any multiple alias this can be considered. The experience 
with MI in C++ was that a seemingly simple idea turned out to have a great deal 
of unexpected complexity, most of it turning up later. And worse, even when all 
that was eventually worked out and the implementation bugs fixed, the benefits 
of MI to programming pretty much failed to materialize.