DIP66 - Multiple alias this

[IgorStepanov via Digitalmars-d]

On Friday, 10 October 2014 at 21:25:17 UTC, Walter Bright wrote:
> On 10/10/2014 10:09 AM, IgorStepanov wrote:
>> Please, comment it.
>
> > static assert(is(C : int)); //Ok, because C is subtype of int
> anyway.
>
> Comment should say that C is implicitly convertible to int

Not really.
int i = C(); //conflict: c.a.i vs c.b.i (thus, C is not 
implicitly convertible to int)

>     struct Test1
>     {
>         int a;
>         int b;
>         alias a this;
>         alias b this; //Error: alias b this conflicts with 
> alias a this;
>     }
>
> DIP says this is "obviously incorrect", but what rule is being 
> applied? I suspect the rule here is if typeof(a)==typeof(b), 
> then it is rejected.
>
> What if typeof(a) is implicitly convertible to typeof(b), and 
> vice-versa?

In current state, if "typeof(a) is implicitly convertible to 
typeof(b), and vice-versa", compiler will accept this alias this 
declaration.
However error may be raised at alias this resolving stage.

> Is alias this resolved before base class search, after base 
> class search, or is it an error if both searches are successful?

In existing alias this implementation alias this resolved after 
base class search.  This DIP inherits it, thus now I suggest to 
check base classes before alias this. Is it acceptable? Should I 
add this into DIP?

> If 'a' and 'b' both contain overloads for function foo, then it 
> should behave like imports do (which is a bit complex).

Hmm. Now it works as I wrote it DIP pseudo-code:
struct A
{
     void foo(string);
     void foo(int);
}

struct B
{
     void foo(double);
}

struct C
{
     A a;
     B b;
     alias a this;
     alias b this;
}

C.foo("test"); //found only one acceptable foo: C.a.foo(string)
C.foo(5);      //1. Check a: found C.a.foo(int);
                //2. Check b: found C.b.foo(double);
                //3. Raise error: C.a.foo(int) vs C.b.foo(double) 
conflict
C.foo(5.0);    //found only one acceptable foo: C.b.foo(double)

Is it Ok?

> Essentially, the rules for multiple alias this should be the 
> same as for multiple imports and multiple mixin templates. 
> These rules work, and the consistency will be expected.

Where can I read about multiple mixin templates?