http://d.puremagic.com/issues/show_bug.cgi?id=5354
--- Comment #16 from Denis Derman <denis.s...@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: -------