On Wednesday, 15 October 2014 at 03:49:41 UTC, Daniel N wrote:
On Wednesday, 15 October 2014 at 02:46:05 UTC, Dicebot wrote:
On Tuesday, 14 October 2014 at 12:33:50 UTC, IgorStepanov
wrote:
This code tell that C is subtype of A and C is subtype of B.
User can use this fact in his code:
void foo(B);
C c = new C;
foo(c); //Ok.
Of course, we shouldn't allow user to cast c to int:
int i = c; //wrong
However, user can explicitly cast c to his subtype, which is
convertable to int:
int i = cast(B)c; //Ok
Summarizing, I disagree with suggestion disallow this code at
type semantic stage.
I agree. It will also make possible to break already working
disambugation of `foo(c)` kind but adding new `alias this` to
one of subtypes independently. That sounds annoying.
I guess the best part of D is, you have the means to fix
anything you disagree with yourself... I can add a static
assert to my class and be happy.
I have another idea, we could define that the shortest
conversion chain wins, analogous to type promotions, that makes
it possible to contain the issue inside C.
class C
{
A a;
B b;
int disambiguate_int()
{
return a;
}
alias a this;
alias b this;
alias disambiguate_int this;
static assert(__traits(compiles, {int _ = C.init;}),
"Ambiguous alias this");
}
i.e. this assert should pass.
In first edition I've implemented rule, when if type defines
alias this directly, this alias hides all indirect aliases with
the same type. However Andrey said that we should implement the
strictest rules as possible and maybe relax them later.
Thus I implemented current rules, but saved the old implemetation
of search. After some time we will able to return to first rule.
It's not hard.
