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