[Issue 5354] formatValue: range templates introduce 3 bugs related to class & struct cases

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=5354



--- Comment #16 from Denis Derman <denis.spir at gmail.com> 2011-01-24 05:40:24 PST ---
(In reply to comment #15)

> This wouldn't work because the dynamic type of the object being formatted can
> differ from the static type the template was instantiated with. Even if the
> compile-time check won't detect the overriden toString, we would still need to
> perform the check at run-time. The easiest way is to compare the address of the
> passed-in object's toString to that of Object.toString. Unfortunately that
> won't work for objects coming from DLLs since they have distinct
> Object.toString functions. So the correct way is to do proper lookup by name
> via run-time reflection.

We may find a way to tell apart, for classes, builtin from toString from custom
one. If we cannot, then in doubt toString must have precedence for classes.
Note there is another bug: one currently cannot implement a range interface on
a class that defines toString (because formatValue template constraints are not
mutually exclusive).
In any case, struct toString must have precedence.

It is an obvious choice: programmers explicitely define toString (later,
writeTo) precisely for that ;-)

Denis

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------