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.

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

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!

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

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.