multiple alias this

[Mr.Bingo]

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.