Re: multiple `alias this` suggestion
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!
Re: multiple `alias this` suggestion
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.
Re: multiple `alias this` suggestion
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/hvdmtvjvccbkmkjzu...@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.
Re: multiple `alias this` suggestion
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/hvdmtvjvccbkmkjzu...@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.
Re: multiple `alias this` suggestion
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/hvdmtvjvccbkmkjzu...@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;
Re: multiple `alias this` suggestion
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/hvdmtvjvccbkmkjzu...@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.
Re: multiple `alias this` suggestion
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.
Re: multiple `alias this` suggestion
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.
Re: multiple `alias this` suggestion
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
}
Re: multiple `alias this` suggestion
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;
}
Re: multiple `alias this` suggestion
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?
Re: multiple `alias this` suggestion
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.
Re: multiple `alias this` suggestion
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.
Re: multiple `alias this` suggestion
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/vkqriubvydntloptg...@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/irjupadpohusatrzo...@forum.dlang.org
Re: multiple `alias this` suggestion
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.
Re: multiple `alias this` suggestion
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.)
Re: multiple `alias this` suggestion
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
Re: multiple `alias this` suggestion
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.
Re: multiple `alias this` suggestion
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!
Re: multiple `alias this` suggestion
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.
Re: multiple `alias this` suggestion
On Fri, Apr 21, 2017 at 08:32:55PM +, 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??
Re: multiple `alias this` suggestion
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.
Re: multiple `alias this` suggestion
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.
Re: multiple `alias this` suggestion
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.
Re: multiple `alias this` suggestion
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.
Re: multiple `alias this` suggestion
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.
Re: multiple `alias this` suggestion
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
Re: multiple `alias this` suggestion
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.
Re: multiple `alias this` suggestion
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
Re: multiple `alias this` suggestion
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?
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?
