The problem, basically, is that when printing a something, if it has an alias this that has toString printable, then it prints that. EG:
//----
struct S1
{
int i;
S2 get()
{
return S2();
}
alias this = get;
}
struct S2
{
const void toString(scope void delegate(const(char)[]) sink)
{
sink("I'm a S2!!!");
}
}
void main()
{
S1 s1 = S1(5);
writeln(s1);
}
//----
Produces:
I'm a S2!!!
When really, I'd have expected:
S1(5)
The problem comes from "hasToString", which mostly checks if "val.toString" is legal, but not if the actual type T *has* the member "toString".
The templates then get confused into thinking the type defines "toString", call "val.toString", which triggers an incorrect call to an alias this cast.
--------
I wrote the corrected code and unittests already, so assigning to self.
Comment #1 by k.hara.pg — 2013-02-08T21:47:57Z
Current behavior is consistent with class inheritance.
class B {
override string toString()
{
return "I'm a B!";
}
}
class C : B {}
void main()
{
C c = new C();
B b = new C();
assert(c.toString() == "I'm a B!");
assert(b.toString() == "I'm a B!");
}
I think that 'alias this' should work as same as normal class inheritance, excepting 'alias this' specific cases.
When I refactored std.format, I designed such literal-like formatting (e.g. "S1(5)") as a *fallback* form. That means: if S1 has toString method (even it is defined in the 'alias this'ed type S2), it will be always used for the formatting of S1 object.
So, it is an expected behavior, and there is no deviation from the design.