Multiple subtyping with alias this and nested classes

Yigal Chripun yigal100 at gmail.com
Tue Oct 6 22:49:38 PDT 2009


On 06/10/2009 09:03, Andrei Alexandrescu wrote:
> Yigal Chripun wrote:
>> On 06/10/2009 02:15, Andrei Alexandrescu wrote:
>>> Yigal Chripun wrote:
>>>>> I think 'alias this' is a powerful feature.
>>>>>
>>>>> Given the constraints like "easy for the compiler writer to implement"
>>>>> and "we have many other things to do", I doubt traits or something
>>>>> like that will be or needs to be in the language.
>>>>
>>>> Alias this is powerful black magic. being powerful doesn't make it any
>>>> less dark.
>>>
>>> So how does this work? Alias this was meant very clearly for allowing
>>> subtyping. Conversely, using it for subtyping is precisely how it was
>>> meant to be used. How exactly did you decide it was a hack or black
>>> magic or whatever?
>>>
>>> Andrei
>>
>> D already has syntax for sub-typing reference types and alias this
>> introduces a completely different syntax doing the same for value
>> types which is bad human interface IMO.
>
> Inheritance is a bit more than just subtyping, for example it entails
> the prefix property (otherwise it wouldn't be very practical). That's
> why D only allows single inheritance of state; multiple inheritance of
> state causes more problems than it solves. That's also why alias this is
> a very flexible complement to inheritance - it offers subtyping without
> requiring the prefix property and leaves layout to the discretion of the
> user.

inheritance is a broken concept as it mixes sub-typing (when you 
implement an interface or protocol) and sub-classing which means 
inheritance of the implementation (state, function bodies).

I said sub-typing and i meant only that:

interface A;
interface B;
struct S: A, B;

S is a sub-type of A and it must provide all the methods as defined by 
A. reference types (classes) provide in addition run-time polymorphism 
since you can have a reference of a base type point to a sub-type object.

consider:

struct A {
int a;
void foo();
}

struct B {
int a;
int b;
void foo();
}

void bar(A a) {
a.foo;
}

it should be possible to say that B is sub-type of A and pass it to bar.


>
>> it also mixes two concepts - sub-typing and opImplicitCast (as i
>> recall, this is done by alias this to a function)
>
> opImplicitCast hasn't been implemented and probably alias this will
> render it unnecessary. I don't see a dangerous conflation.
>
exactly. alias this can also do what opImplicitCast was means to do.

>> we discussed this in the past already and IIRC you agreed with me
>> about implementing compile time inheritance for structs which I feel
>> is much cleaner and more consistent with the existing syntax of
>> interfaces.
>
> Maybe there's a misunderstanding. Inheritance of interfaces for structs
> (which is different from what alias this helps with) was something that
> Walter and I considered interesting to pursue for simplifying concept
> checking. However, recent developments clarified that that's not enough
> (I even deleted the related enhancement requests from bugzilla).
> Currently I'm considering a reflection-based concept checking, but it's
> too crude an idea to discuss it at the moment.
>
>
> Andrei

can you elaborate on why is this not enough? what else is missing?


My understanding is that alias this provides two things:
implicit convert
sub-typing

IMO, explicit convert is better than the former and the latter should be 
provided by interfaces.

struct A;
struct B {
alias this A;
...
}

this is the same as saying:
interface I;
struct A : I;
struct B: I;




More information about the Digitalmars-d mailing list