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?
