www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - multiple alias this

reply Mr.Bingo <Bingo Namo.com> writes:
An implementation method:

Single `alias this` already works, this method leverages it to 
create a multiple `alias this`. This method is presented for a 
basic review

1.
     alias a,b,... this;

Is this proposed syntax used for assigning multiple sinks for the 
dispatching of access '.' operator. It is also called an `alias 
this` with multiple implicit for the case of one alias.

     struct X
     {
        int a;
        string s;
        alias a,s this
     }
     X x;
     void foo(T)(T x);

2.

Here the compiler chooses which alias works by inference. foo(x) 
fails because of ambiguity in that it accepts both aliases. The 
proposed rule is that that an `alias this` must resolve to one 
and only one alias. This rule allows the original single `alias 
this` algorithm to work for multiple `alias this` by effectively 
adding a loop in the testing section of the code(we test for each 
alias and if only one is successful then success, else failure)


This rule prevents such things as

     struct X
     {
        int a;
        int b;
        double c;
        string s;
        alias a,b,c,s this
     }


because b and a are the same type and both will resolve the 
inferencing rule giving at least 2 variables rather than the one 
required by the rule.

c and s may or may not fail depending on context.


The simplification here is that no other code anywhere dealing 
with the use of multiple `alias this` needs to be modified such 
as templates, traits, runtime, etc.


If the single alias this code that determines if the alias is 
active is represented by SA!(T,typeof(aliasthis)) which returns 
true if the type of the single `alias this` is T, the parameter 
or object "returned", then multiple `alias this` looks something 
like

int count = 0;
foreach(ma; multiplealiasthislist)
   count += (SA!(T,typeof(aliasthis))) ? 1 : 0;

if (count != 1) error();


when the single `alias this` code would look like

if (!SA!(T,typeof(aliasthis))) error();

For `.` access each type is checked in the loop in a similar 
manner for only one solution.

3. Why this works is because for orthogonal types we'ed expect no 
issues and that generally will be the case. Therefore we simply 
limit multiple `alias this` to the case where all the types are 
orthogonal. (convenient way to solve the problem, but 
orthogonality is easily defined in D)

For non-orthogonal types we just error out and let the programmer 
figure out the proper solution.

D can attempt to check if all the types are orthogonal at compile 
time in two ways. Either at the declaration of the alias this or 
at the resolving point. If it is done at resolution then it 
relaxes orthogonality requirements by allowing some cases to pass 
simply because the context allows it but it could fail the 
resolve when the program has been modified.

4. e.g., for a 2-ply multiple `alias this` we have something like 
X given above.

    x and s are not orthogonal in all cases, specially with 
templates and so either the compiler can fail when parsing X or 
it can wait to test which types work in which circumstances and 
fail only if there is an ambiguity. The last way is the way D 
generally works as it offers a more relaxed error checking which 
allows many cases to work while also allowing for a more slightly 
brittle programming experience(which may not effect most people).


5. Templates are a special problem since they can accept any 
possible type, and a multiple alias this effectively is a 
multiple type. One can instantiate the template on all versions 
and if only one passes then that version is used, but this is 
prone to errors since what the programmer may think is the passed 
alias is not, and some corner cases it would be a difficult bug 
to detect.

6. reflection/traits should allow getting the multiple alias 
types and variable names.
Jul 19 2018
next sibling parent reply Mike Franklin <slavo5150 yahoo.com> writes:
On Friday, 20 July 2018 at 00:26:43 UTC, Mr.Bingo wrote:

 [...]


I didn't read through all of that, but just so you are aware, a 
*multiple alias this* DIP was already approved.  You can find it 
at https://wiki.dlang.org/DIP66

The implementation is already started and you can find it at 
https://github.com/dlang/dmd/pull/8378, but it's a big PR and 
reviewers are going to need time and effort to understand and 
analyze it.  I hope it will be merged this release cycle, but 
that's just my optimism talking.

Mike
Jul 20 2018
parent reply Michelle Long <HappyDance321 gmail.com> writes:
On Friday, 20 July 2018 at 07:07:51 UTC, Mike Franklin wrote:

 On Friday, 20 July 2018 at 00:26:43 UTC, Mr.Bingo wrote:

 [...]


 I didn't read through all of that, but just so you are aware, a 
 *multiple alias this* DIP was already approved.  You can find 
 it at https://wiki.dlang.org/DIP66

 The implementation is already started and you can find it at 
 https://github.com/dlang/dmd/pull/8378, but it's a big PR and 
 reviewers are going to need time and effort to understand and 
 analyze it.  I hope it will be merged this release cycle, but 
 that's just my optimism talking.

 Mike


Actually,

"It doesn't introduce multiple alias this"

and nothing has been done for a few months.

I've seen snails moves faster!
Oct 25 2018
parent Norm <norm.rowtree gmail.com> writes:
On Friday, 26 October 2018 at 00:42:58 UTC, Michelle Long wrote:

 On Friday, 20 July 2018 at 07:07:51 UTC, Mike Franklin wrote:

 On Friday, 20 July 2018 at 00:26:43 UTC, Mr.Bingo wrote:

 [...]


 I didn't read through all of that, but just so you are aware, 
 a *multiple alias this* DIP was already approved.  You can 
 find it at https://wiki.dlang.org/DIP66

 The implementation is already started and you can find it at 
 https://github.com/dlang/dmd/pull/8378, but it's a big PR and 
 reviewers are going to need time and effort to understand and 
 analyze it.  I hope it will be merged this release cycle, but 
 that's just my optimism talking.

 Mike


 Actually,

 "It doesn't introduce multiple alias this"

 and nothing has been done for a few months.

 I've seen snails moves faster!


I guess it is not a trivial thing to implement. If you have a 
solution for multiple alias this that is simpler/quicker to 
implement then you can comment on the PR, if not I guess it is 
just "as long as it takes".

bye,
Norm
Oct 25 2018
prev sibling parent Basile B. <b2.temp gmx.com> writes:
On Friday, 20 July 2018 at 00:26:43 UTC, Mr.Bingo wrote:

 An implementation method:

 Single `alias this` already works, this method leverages it to 
 create a multiple `alias this`. This method is presented for a 
 basic review

 1.
     alias a,b,... this;

 Is this proposed syntax used for assigning multiple sinks for 
 the dispatching of access '.' operator. It is also called an 
 `alias this` with multiple implicit for the case of one alias.

     struct X
     {
        int a;
        string s;
        alias a,s this
     }
     X x;
     void foo(T)(T x);

 2.

 Here the compiler chooses which alias works by inference. 
 foo(x) fails because of ambiguity in that it accepts both 
 aliases. The proposed rule is that that an `alias this` must 
 resolve to one and only one alias. This rule allows the 
 original single `alias this` algorithm to work for multiple 
 `alias this` by effectively adding a loop in the testing 
 section of the code(we test for each alias and if only one is 
 successful then success, else failure)


That sounds extremely naive Mr Bingo. You think that because you 
add a comma separated list you can just write a loop on top of 
existing compiler code ? Semantic is much less tied to the syntax 
than you think.
Oct 25 2018