multiple `alias this` suggestion

Currently only one `alias this` declaration is permitted, and the documentation https://dlang.org/spec/class.html#AliasThis says the following.

"Multiple AliasThis are allowed. For implicit conversions and forwarded lookups, all AliasThis declarations are attempted; if more than one AliasThis is eligible, the ambiguity is disallowed by raising an error. Note: Multiple AliasThis is currently unimplemented."

However the effect of multiple `alias this` declarations can be approximated in existing D using only single `alias this`, e.g. in the following three members each with `alias this` are simulated.

//========================
struct member1
{
    int n1, n2, n3;
}

struct member2
{
    int n2, n3;
    member1 member;
    alias member this;
}

struct member3
{
    int n3;
    member2 member;
    alias member this;
}

struct top
{
    member3 member;
    alias member this;

    this(int i, int j, int k)
    {
        n1 = i; n2 = j; n3 = k;
    }
}


void main()
{
    auto x = top(1,2,3);
    member3 m3 = x.member;
    member2 m2 = m3.member;
    member1 m1 = m2.member;

    import std.stdio;
    writefln("%s %s %s", m1.n1, m1.n2, m1.n3);
    writefln("%s %s %s", m2.n1, m2.n2, m2.n3);
    writefln("%s %s %s", m3.n1, m3.n2, m3.n3);
    writefln("%s %s %s", x.n1, x.n2, x.n3);
}
//========================

Which outputs the following as expected from chaining the effects of `alias this`.

1 0 0
1 2 0
1 2 3
1 2 3

Note that this construction provides a natural hierarchy for name lookup, unlike the statement above taken from the documentation.

Imagine the existing single `alias this` is extended to provide such a heierarchy of lookups. For example,

struct top
{
    mem3 m3;
    mem2 m2;
    mem1 m1;
    alias m3, m2, m1 this;
    // ...
}

could be interpreted to mean search for a name in m3 if not found in top, and in m2 if not found in m3 and in m1 if not found in m2. I don't back the syntax, just the notion.

Maybe that's not all that's expected from "multiple alias this" but it would be a clean step forward. Issues?

On Wednesday, 19 April 2017 at 18:32:43 UTC, Carl Sturtivant wrote: > Imagine the existing single `alias this` is extended to provide such a heierarchy of lookups. For example, > > struct top > { > mem3 m3; > mem2 m2; > mem1 m1; > alias m3, m2, m1 this; > // ... > } > > could be interpreted to mean search for a name in m3 if not found in top, and in m2 if not found in m3 and in m1 if not found in m2. I don't back the syntax, just the notion. > > Maybe that's not all that's expected from "multiple alias this" but it would be a clean step forward. Issues? No issues then! Time for a D I P perhaps. Comment?

On 04/20/2017 04:35 PM, Carl Sturtivant wrote: > On Wednesday, 19 April 2017 at 18:32:43 UTC, Carl Sturtivant wrote: >> Imagine the existing single `alias this` is extended to provide such a >> heierarchy of lookups. For example, >> >> struct top >> { >> mem3 m3; >> mem2 m2; >> mem1 m1; >> alias m3, m2, m1 this; >> // ... >> } >> >> could be interpreted to mean search for a name in m3 if not found in >> top, and in m2 if not found in m3 and in m1 if not found in m2. I >> don't back the syntax, just the notion. >> >> Maybe that's not all that's expected from "multiple alias this" but it >> would be a clean step forward. Issues? > > No issues then! > Time for a D I P perhaps. > Comment? This is interesting, and would be timely to discuss before an implementation of multiple alias this gets started. -- Andrei

On Thursday, 20 April 2017 at 20:35:04 UTC, Carl Sturtivant wrote: > On Wednesday, 19 April 2017 at 18:32:43 UTC, Carl Sturtivant wrote: >> Imagine the existing single `alias this` is extended to provide such a heierarchy of lookups. For example, >> >> struct top >> { >> mem3 m3; >> mem2 m2; >> mem1 m1; >> alias m3, m2, m1 this; >> // ... >> } >> >> could be interpreted to mean search for a name in m3 if not found in top, and in m2 if not found in m3 and in m1 if not found in m2. I don't back the syntax, just the notion. >> >> Maybe that's not all that's expected from "multiple alias this" but it would be a clean step forward. Issues? > > No issues then! > Time for a D I P perhaps. > Comment? auto x = top(1,2,3); void takesMember1(member1) {} void takesMember2(member2) {} void takesMember3(member3) {} static assert(__traits(compiles, { takesMember1(x); })); //Passes static assert(__traits(compiles, { takesMember2(x); })); //Passes static assert(__traits(compiles, { takesMember3(x); })); //Passes This is a little bit surprising until you think about it a bit. It's also how we would want multiple alias this to behave were it implemented, which is a plus.

On 4/21/17 8:17 AM, Andrei Alexandrescu wrote: > On 04/20/2017 04:35 PM, Carl Sturtivant wrote: >> On Wednesday, 19 April 2017 at 18:32:43 UTC, Carl Sturtivant wrote: >>> Imagine the existing single `alias this` is extended to provide such a >>> heierarchy of lookups. For example, >>> >>> struct top >>> { >>> mem3 m3; >>> mem2 m2; >>> mem1 m1; >>> alias m3, m2, m1 this; >>> // ... >>> } >>> >>> could be interpreted to mean search for a name in m3 if not found in >>> top, and in m2 if not found in m3 and in m1 if not found in m2. I >>> don't back the syntax, just the notion. >>> >>> Maybe that's not all that's expected from "multiple alias this" but it >>> would be a clean step forward. Issues? >> >> No issues then! >> Time for a D I P perhaps. >> Comment? > > This is interesting, and would be timely to discuss before an > implementation of multiple alias this gets started. -- Andrei > I agree, I like how this solves the ambiguity problem nicely. However, this disallows using introspection to declare multiple alias this piecemeal. e.g.: struct S(bool foo) { int x; alias x this; static if(foo) { string y; alias y this; } } One thing we can do also is just use declaration order to prioritize which alias this to use. -Steve

On Wednesday, 19 April 2017 at 18:32:43 UTC, Carl Sturtivant wrote: > > struct top > { > mem3 m3; > mem2 m2; > mem1 m1; > alias m3, m2, m1 this; > // ... > } > I thought they were deprecating the comma operator.

On Fri, Apr 21, 2017 at 08:17:28AM -0400, Andrei Alexandrescu via Digitalmars-d wrote: [...] > This is interesting, and would be timely to discuss before an implementation of multiple alias this gets started. -- Andrei Whatever happened to the almost-complete implementation of alias this that was sitting in the PR queue a while back? Have we just let it bitrot into oblivion? :-( T -- The trouble with TCP jokes is that it's like hearing the same joke over and over.

On Friday, 21 April 2017 at 16:21:57 UTC, H. S. Teoh wrote: > On Fri, Apr 21, 2017 at 08:17:28AM -0400, Andrei Alexandrescu via Digitalmars-d wrote: [...] >> This is interesting, and would be timely to discuss before an implementation of multiple alias this gets started. -- Andrei > > Whatever happened to the almost-complete implementation of alias this that was sitting in the PR queue a while back? Have we just let it bitrot into oblivion? :-( > > > T https://github.com/dlang/dmd/pull/3998/files It's written against C++ DMD as it was in 2014 so it may not be feasible anymore to easily port it to DDMD.

On Friday, 21 April 2017 at 16:41:45 UTC, Meta wrote: > On Friday, 21 April 2017 at 16:21:57 UTC, H. S. Teoh wrote: >> On Fri, Apr 21, 2017 at 08:17:28AM -0400, Andrei Alexandrescu via Digitalmars-d wrote: [...] >>> This is interesting, and would be timely to discuss before an implementation of multiple alias this gets started. -- Andrei >> >> Whatever happened to the almost-complete implementation of alias this that was sitting in the PR queue a while back? Have we just let it bitrot into oblivion? :-( >> >> >> T R > https://github.com/dlang/dmd/pull/3998/files > > It's written against C++ DMD as it was in 2014 so it may not be feasible anymore to easily port it to DDMD. This one looks easy to port. However I am not sure if those are disired semantics and that was one of the points raised against the PR iirc.

Forums