www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - multiple `alias this` suggestion

reply Carl Sturtivant <sturtivant gmail.com> writes:
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?
Apr 19 2017
next sibling parent reply Carl Sturtivant <sturtivant gmail.com> writes:
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?
Apr 20 2017
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Apr 21 2017
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Apr 21 2017
next sibling parent reply Carl Sturtivant <sturtivant gmail.com> writes:
On Friday, 21 April 2017 at 14:55:31 UTC, Steven Schveighoffer 
wrote:

 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.


Not necessary in this case:

struct S(bool foo)
{
   int x;
   static if(!foo)
   {
      alias x this;
   }
   else
   {
      string y;
      alias x, y this;
   }
}

It's easier to analyze if  isn't distributed, i.e. if only one 
location applies.
Apr 24 2017
next sibling parent Carl Sturtivant <sturtivant gmail.com> writes:
On Monday, 24 April 2017 at 16:52:49 UTC, Carl Sturtivant wrote:

 On Friday, 21 April 2017 at 14:55:31 UTC, Steven Schveighoffer 
 wrote:

 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.


 Not necessary in this case:

 struct S(bool foo)
 {
   int x;
   static if(!foo)
   {
      alias x this;
   }
   else
   {
      string y;
      alias x, y this;
   }
 }

 It's easier to analyze if  isn't distributed, i.e. if only one 
 location applies.


It's easier to analyze if AliasThis isn't distributed, i.e. if 
only one location appears in a given instantiation.
Apr 26 2017
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/24/17 12:52 PM, Carl Sturtivant wrote:

 On Friday, 21 April 2017 at 14:55:31 UTC, Steven Schveighoffer wrote:

 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.


 Not necessary in this case:

 struct S(bool foo)
 {
   int x;
   static if(!foo)
   {
      alias x this;
   }
   else
   {
      string y;
      alias x, y this;
   }
 }

 It's easier to analyze if  isn't distributed, i.e. if only one location
 applies.


I think you can appreciate that this doesn't scale. Imagine a case which 
has 2 or 3 optional alias this items.

-Steve
Apr 26 2017
parent reply Carl Sturtivant <sturtivant gmail.com> writes:
On Wednesday, 26 April 2017 at 15:00:30 UTC, Steven Schveighoffer 
wrote:

 I think you can appreciate that this doesn't scale. Imagine a 
 case which has 2 or 3 optional alias this items.

 -Steve


Agreed, not manually, as it is exponential in the number of 
conditions. But I think some template machinery could mixin the 
right stuff in one place avoiding that problem, implanting the 
existing names in an `alias this`. So
   AliasThis!(x,y,z)
which could detect if each name exists in an instantiation and 
only use that name if so, and would be placed outside of any 
`static if` to do the job.

I'm leaning toward the notion that a single AliasThis of the kind 
I suggested  with a suitable template library to help out with 
matters such as the one you raised is enough.

(Some name management for shadowed names could be in that library 
too --- different topic, will discuss elsewhere.)
Apr 26 2017
parent reply Daniel N <no public.email> writes:
On Wednesday, 26 April 2017 at 18:34:48 UTC, Carl Sturtivant 
wrote:

 On Wednesday, 26 April 2017 at 15:00:30 UTC, Steven 
 Schveighoffer wrote:

 I think you can appreciate that this doesn't scale. Imagine a 
 case which has 2 or 3 optional alias this items.

 -Steve


 Agreed, not manually, as it is exponential in the number of 
 conditions.


Image using frameworks which conveniently allow adding features 
to a struct...

struct Beholder
{
   mixin Entity!Movable;
   mixin Render!"Beholder.png";
}

... then you couldn't even solve it manually without rewriting 
the framework.

With distributed 'alias this' you could seamlessly combine any 
number of frameworks from different vendors.
Apr 26 2017
next sibling parent reply Carl Sturtivant <sturtivant gmail.com> writes:
On Thursday, 27 April 2017 at 05:41:43 UTC, Daniel N wrote:

 On Wednesday, 26 April 2017 at 18:34:48 UTC, Carl Sturtivant 
 wrote:

 On Wednesday, 26 April 2017 at 15:00:30 UTC, Steven 
 Schveighoffer wrote:

 I think you can appreciate that this doesn't scale. Imagine a 
 case which has 2 or 3 optional alias this items.

 -Steve


 Agreed, not manually, as it is exponential in the number of 
 conditions.


 Image using frameworks which conveniently allow adding features 
 to a struct...

 struct Beholder
 {
   mixin Entity!Movable;
   mixin Render!"Beholder.png";
 }

 ... then you couldn't even solve it manually without rewriting 
 the framework.

 With distributed 'alias this' you could seamlessly combine any 
 number of frameworks from different vendors.


Please explain "seamlessly" with the prospect of name collisions.
Apr 27 2017
parent reply Carl Sturtivant <sturtivant gmail.com> writes:
On Friday, 28 April 2017 at 04:44:44 UTC, Carl Sturtivant wrote:

 On Thursday, 27 April 2017 at 05:41:43 UTC, Daniel N wrote:

 On Wednesday, 26 April 2017 at 18:34:48 UTC, Carl Sturtivant 
 wrote:

 On Wednesday, 26 April 2017 at 15:00:30 UTC, Steven 
 Schveighoffer wrote:

 I think you can appreciate that this doesn't scale. Imagine 
 a case which has 2 or 3 optional alias this items.

 -Steve


 Agreed, not manually, as it is exponential in the number of 
 conditions.


 Image using frameworks which conveniently allow adding 
 features to a struct...

 struct Beholder
 {
   mixin Entity!Movable;
   mixin Render!"Beholder.png";
 }

 ... then you couldn't even solve it manually without rewriting 
 the framework.

 With distributed 'alias this' you could seamlessly combine any 
 number of frameworks from different vendors.


 Please explain "seamlessly" with the prospect of name 
 collisions.


:) Disclosure: I have a negative view of mixin templates. 
Entanglement with names at the landing site is unhappy.

The idea of mixin template instantations bringing in AliasThis 
declarations is amplifying my negative view. Still, I suppose 
this could be made to work following analogous rules. Yuck.

Do we even need mixin templates when some form of multiple 
AliasThis is available? And if that form is really clean, haven't 
we then gained something?
Apr 27 2017
parent reply Daniel N <no public.email> writes:
On Friday, 28 April 2017 at 05:32:36 UTC, Carl Sturtivant wrote:

 On Friday, 28 April 2017 at 04:44:44 UTC, Carl Sturtivant wrote:

 On Thursday, 27 April 2017 at 05:41:43 UTC, Daniel N wrote:

 On Wednesday, 26 April 2017 at 18:34:48 UTC, Carl Sturtivant 
 wrote:

 On Wednesday, 26 April 2017 at 15:00:30 UTC, Steven 
 Schveighoffer wrote:

 I think you can appreciate that this doesn't scale. Imagine 
 a case which has 2 or 3 optional alias this items.

 -Steve


 Agreed, not manually, as it is exponential in the number of 
 conditions.


 Image using frameworks which conveniently allow adding 
 features to a struct...

 struct Beholder
 {
   mixin Entity!Movable;
   mixin Render!"Beholder.png";
 }

 ... then you couldn't even solve it manually without 
 rewriting the framework.

 With distributed 'alias this' you could seamlessly combine 
 any number of frameworks from different vendors.


 Please explain "seamlessly" with the prospect of name 
 collisions.


 :) Disclosure: I have a negative view of mixin templates. 
 Entanglement with names at the landing site is unhappy.


You don't have to fear mixin collisions since there is an 
awesomely designed builtin feature to solve this issue.

mixin template fun() { int a; }

struct A
{
     mixin fun f1;
     mixin fun f2;
}

void main()
{
     auto a = A();

     a.f1.a = 1;
     a.f2.a = 2;
}
Apr 28 2017
parent Carl Sturtivant <sturtivant gmail.com> writes:
On Friday, 28 April 2017 at 07:07:44 UTC, Daniel N wrote:

 On Friday, 28 April 2017 at 05:32:36 UTC, Carl Sturtivant wrote:

 On Friday, 28 April 2017 at 04:44:44 UTC, Carl Sturtivant 
 wrote:

 On Thursday, 27 April 2017 at 05:41:43 UTC, Daniel N wrote:

 On Wednesday, 26 April 2017 at 18:34:48 UTC, Carl Sturtivant 
 wrote:

 On Wednesday, 26 April 2017 at 15:00:30 UTC, Steven 
 Schveighoffer wrote:

 I think you can appreciate that this doesn't scale. 
 Imagine a case which has 2 or 3 optional alias this items.

 -Steve


 Agreed, not manually, as it is exponential in the number of 
 conditions.


 Image using frameworks which conveniently allow adding 
 features to a struct...

 struct Beholder
 {
   mixin Entity!Movable;
   mixin Render!"Beholder.png";
 }

 ... then you couldn't even solve it manually without 
 rewriting the framework.

 With distributed 'alias this' you could seamlessly combine 
 any number of frameworks from different vendors.


 Please explain "seamlessly" with the prospect of name 
 collisions.


 :) Disclosure: I have a negative view of mixin templates. 
 Entanglement with names at the landing site is unhappy.


 You don't have to fear mixin collisions since there is an 
 awesomely designed builtin feature to solve this issue.

 mixin template fun() { int a; }

 struct A
 {
     mixin fun f1;
     mixin fun f2;
 }

 void main()
 {
     auto a = A();

     a.f1.a = 1;
     a.f2.a = 2;
 }


If having templates with dynamic bindings (set at the landing 
site) of some kind is obligatory, then this is about as good as 
it can get. I wouldn't call it awesome except in the sense that 
it cleverly makes the best of an awkward situation. It's not a 
clean abstraction: subsequently mixing in more "features of a 
struct" into your struct can make a formerly usable name in the 
outside world unusable.

However I am trying to arrive at a mechanism whereby this is 
unnecessary.

AliasThis has the same issues as led to the definition of mixin 
templates if there are multiple such. So there are two broad 
paths that could be followed. The first is to just swallow a 
similar mechanism as mixin templates, and try to allow arbitrary 
interaction among many distributed AliasThis declarations with 
fallback to fully qualified names in the event of ambiguity as in 
your example.

The second path is to endeavor to create a different mechanism 
that does not suffer from that approach, so an additional entity 
can be added to the list of things being aliased-to-this without 
making existing names unusable outside of the definition being 
made, exactly the way mixin templates don't.

I am trying to explore this second path.
Apr 29 2017
prev sibling next sibling parent Carl Sturtivant <sturtivant gmail.com> writes:
On Thursday, 27 April 2017 at 05:41:43 UTC, Daniel N wrote:

 On Wednesday, 26 April 2017 at 18:34:48 UTC, Carl Sturtivant 
 wrote:

 On Wednesday, 26 April 2017 at 15:00:30 UTC, Steven 
 Schveighoffer wrote:

 I think you can appreciate that this doesn't scale. Imagine a 
 case which has 2 or 3 optional alias this items.

 -Steve


 Agreed, not manually, as it is exponential in the number of 
 conditions.


 Image using frameworks which conveniently allow adding features 
 to a struct...

 struct Beholder
 {
   mixin Entity!Movable;
   mixin Render!"Beholder.png";
 }

 ... then you couldn't even solve it manually without rewriting 
 the framework.


Here's a way to use single hierarchical AliasThis as per this 
thread without editing vendor code. No special mechanism for name 
collisions is needed.

// contain arbitrary names from vendors, & do some renaming if 
desired
struct EntityWrapper(T)
{
     //one hierarchical AliasThis in here (or none)
   mixin Entity!T;
}
struct RenderWrapper(string s)
{
     //one hierarchical AliasThis in here (or none)
   mixin Render!s;
   alias t2 = t; //e.g.
}

struct Beholder
{
   EntityWrapper!Movable entity;
   RenderWrapper!"Beholder.png" render;
     //one hierarchical AliasThis in here
   alias entity, render this; //if render.t is shadowed, it gets 
out as t2
}
Apr 29 2017
prev sibling parent reply Carl Sturtivant <sturtivant gmail.com> writes:
On Thursday, 27 April 2017 at 05:41:43 UTC, Daniel N wrote:

 On Wednesday, 26 April 2017 at 18:34:48 UTC, Carl Sturtivant 
 wrote:

 On Wednesday, 26 April 2017 at 15:00:30 UTC, Steven


 Image using frameworks which conveniently allow adding features 
 to a struct...

 struct Beholder
 {
   mixin Entity!Movable;
   mixin Render!"Beholder.png";
 }


Why distribute features as mixin templates when with AliasThis 
fully implemented they can be distributed as structs and are 
therefore encapsulated?

struct Beholder
{
     //now Entity(T) is a struct template, not a mixin template
   Entity!Movable entity;
     //ditto
   Render!"Beholder.png" render;
     //in my hierarchical form
   alias entity, render this;
}

Even better, with alias for embedded aliased-to-this structs made 
working usefully, name management can be done before embedding 
the features, by having another layer of embedding as in my 
earlier example here.
https://forum.dlang.org/post/hvdmtvjvccbkmkjzuclm forum.dlang.org

Broadly speaking, a mixin template is just "a bunch of 
unencapsulated declarations". And AliasThis is a way to remove a 
layer of encapsulation from "a bunch of declarations". (Though it 
cannot be used currently outside of a struct or class.) This just 
screams for simplification.
Apr 29 2017
parent reply Daniel N <no public.email> writes:
On Saturday, 29 April 2017 at 23:57:07 UTC, Carl Sturtivant wrote:

 On Thursday, 27 April 2017 at 05:41:43 UTC, Daniel N wrote:

 Even better, with alias for embedded aliased-to-this structs 
 made working usefully, name management can be done before 
 embedding the features, by having another layer of embedding as 
 in my earlier example here.
 https://forum.dlang.org/post/hvdmtvjvccbkmkjzuclm forum.dlang.org


OK, you have a point.

I realise syntax is the least important part of this proposal, 
but "alias this" is the only alias that still is backwards...

If you do write a DIP at least consider this:
alias this : entity, render;
May 03 2017
parent reply Daniel N <no public.email> writes:
On Wednesday, 3 May 2017 at 19:41:58 UTC, Daniel N wrote:

 On Saturday, 29 April 2017 at 23:57:07 UTC, Carl Sturtivant 
 wrote:

 On Thursday, 27 April 2017 at 05:41:43 UTC, Daniel N wrote:

 Even better, with alias for embedded aliased-to-this structs 
 made working usefully, name management can be done before 
 embedding the features, by having another layer of embedding 
 as in my earlier example here.
 https://forum.dlang.org/post/hvdmtvjvccbkmkjzuclm forum.dlang.org


 OK, you have a point.

 I realise syntax is the least important part of this proposal, 
 but "alias this" is the only alias that still is backwards...

 If you do write a DIP at least consider this:
 alias this : entity, render;


PS One could of course eat the cake and keep it still, at the 
cost of additional complexity.

Distributed and prioritized:
alias this : a_prio1, a_prio2, a_prio3;
alias this : b_prio1, b_prio2;

any a* could clash with any b* but a:s wont clash with their own 
kind since they are internally prioritised the same goes for b:s.
May 03 2017
parent reply Carl Sturtivant <sturtivant gmail.com> writes:
On Wednesday, 3 May 2017 at 19:52:46 UTC, Daniel N wrote:

 On Wednesday, 3 May 2017 at 19:41:58 UTC, Daniel N wrote:

 On Saturday, 29 April 2017 at 23:57:07 UTC, Carl Sturtivant 
 wrote:

 On Thursday, 27 April 2017 at 05:41:43 UTC, Daniel N wrote:

 Even better, with alias for embedded aliased-to-this structs 
 made working usefully, name management can be done before 
 embedding the features, by having another layer of embedding 
 as in my earlier example here.
 https://forum.dlang.org/post/hvdmtvjvccbkmkjzuclm forum.dlang.org


 OK, you have a point.

 I realise syntax is the least important part of this proposal, 
 but "alias this" is the only alias that still is backwards...

 If you do write a DIP at least consider this:
 alias this : entity, render;


 PS One could of course eat the cake and keep it still, at the 
 cost of additional complexity.

 Distributed and prioritized:
 alias this : a_prio1, a_prio2, a_prio3;
 alias this : b_prio1, b_prio2;

 any a* could clash with any b* but a:s wont clash with their 
 own kind since they are internally prioritised the same goes 
 for b:s.


Reasonable. I may eventually resort to this possibility, but 
right now I am trying to force out the consequences of avoiding 
this extra complexity. (And syntax, yes, noted.)

Not finished posting to this thread yet.
May 04 2017
parent reply Seb <seb wilzba.ch> writes:
On Thursday, 4 May 2017 at 14:09:49 UTC, Carl Sturtivant wrote:

 Reasonable. I may eventually resort to this possibility, but 
 right now I am trying to force out the consequences of avoiding 
 this extra complexity. (And syntax, yes, noted.)

 Not finished posting to this thread yet.


As no one pointed it out before, FYI there has been a previous 
DIP (https://wiki.dlang.org/DIP66) on which the old dmd PR was 
based on.
May 06 2017
parent Carl Sturtivant <sturtivant gmail.com> writes:
On Saturday, 6 May 2017 at 10:18:24 UTC, Seb wrote:

 As no one pointed it out before, FYI there has been a previous 
 DIP (https://wiki.dlang.org/DIP66) on which the old dmd PR was 
 based on.


Glad you mentioned that!
May 06 2017
prev sibling parent Carl Sturtivant <sturtivant gmail.com> writes:
On Friday, 21 April 2017 at 14:55:31 UTC, Steven Schveighoffer 
wrote:

 One thing we can do also is just use declaration order to 
 prioritize which alias this to use.


Presumably using declaration order as a means of prioritizing 
which name wins was rejected as a design possibility in the case 
of mixin templates which don't do this.

There is a strong parallel between name collisions between 
multiple mixin template instantions in the same scope, and 
muliple AliasThis declarations in the same scope: both bring an 
arbitrary collection of names and their concomitant collisions 
into that scope.

So presumably using declaration order as a means of prioritizing 
which name wins in the case of AliasThis would be rejected for 
the same reasons as for mixin templates.
Apr 29 2017
prev sibling next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
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.
Apr 21 2017
parent reply Meta <jared771 gmail.com> writes:
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.
Apr 21 2017
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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.
Apr 21 2017
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Apr 21, 2017 at 08:32:55PM +0000, Stefan Koch via Digitalmars-d wrote:

 On Friday, 21 April 2017 at 16:41:45 UTC, Meta wrote:


[...]

 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.


I see. So the first thing to do is to work out the desired semantics,
before we make another attempt at implementing it.


T

-- 
Who told you to swim in Crocodile Lake without life insurance??
Apr 22 2017
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/21/2017 5:17 AM, Andrei Alexandrescu wrote:

 This is interesting, and would be timely to discuss before an implementation of
 multiple alias this gets started. -- Andrei


mixin templates already have an established method for resolving overloads and 
such with the names they introduce. Any multiple alias this solution should 
investigate any parallels with that.
Apr 26 2017
parent Carl Sturtivant <sturtivant gmail.com> writes:
On Wednesday, 26 April 2017 at 20:19:19 UTC, Walter Bright wrote:

 On 4/21/2017 5:17 AM, Andrei Alexandrescu wrote:

 This is interesting, and would be timely to discuss before an 
 implementation of
 multiple alias this gets started. -- Andrei


 mixin templates already have an established method for 
 resolving overloads and such with the names they introduce. Any 
 multiple alias this solution should investigate any parallels 
 with that.


The suggestion for multiple alias this I postulate in the 
original post in this thread is a clean way to avoid that 
complexity. Here's a summary.
https://forum.dlang.org/post/vkqriubvydntloptgfit forum.dlang.org

I am leaning toward the view that with some template support from 
a small library, to help use it effectively inside templates, 
that it provides a simple and effective solution to the problem. 
Here's one postulated template.
https://forum.dlang.org/post/irjupadpohusatrzowqu forum.dlang.org
Apr 26 2017
prev sibling parent reply Meta <jared771 gmail.com> writes:
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.
Apr 21 2017
parent Carl Sturtivant <sturtivant gmail.com> writes:
On Friday, 21 April 2017 at 14:51:42 UTC, Meta wrote:

 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.


Nice!
Apr 24 2017
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
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.
Apr 21 2017
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 21 April 2017 at 15:30:14 UTC, jmh530 wrote:

     alias m3, m2, m1 this;


 I thought they were deprecating the comma operator.


That's not the comma operator.
Apr 21 2017