[Issue 5354] formatValue: range templates introduce 3 bugs related to class & struct cases
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Sun Jan 23 13:30:59 PST 2011
http://d.puremagic.com/issues/show_bug.cgi?id=5354
--- Comment #12 from Andrei Alexandrescu <andrei at metalanguage.com> 2011-01-23 13:28:48 PST ---
There are good arguments for going either way wrt the relative priority of
toString and range interface.
Using toString by default is in a way the "right" thing to do as it's the
default formatting for all non-range objects. For class objects, I oppose
distinguishing between introduced toString and inherited toString; that goes
against what inheritance is about.
There are a few problems with toString, however. It needs to format everything
in memory before writing, which makes formatting large ranges slow. Also, if
you have a range but you want to use toString it's easy to simply write
r.toString, whereas there is no simple method to say "even though this range
has toString, please use the range functions to format it".
It's true that there's a danger of accidental conformance to inputRange. But at
this point the input range troika is about as widespread as toString, so I
don't think that's a major risk.
I have the changes proposed by Nick with a few edits in my tree. Unless a solid
argument comes forward, I'll commit them soon.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
More information about the Digitalmars-d-bugs
mailing list