On Sun, 21 Nov 2010 05:10:13 -0500, spir <[email protected]> wrote:
On Thu, 18 Nov 2010 17:21:20 -0500
"Steven Schveighoffer" <[email protected]> wrote:
I just created a new D Improvement Proposal to fix the toString problem
I
brought up several posts ago.
See: http://prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP9
Hello,
[Sorry for a partly personal message, but I cannot help it. At first
sight, my gut reaction in front of this proposal has been: no, nooo,
NOOO!!! I waited a few days because, _surely_, I was missing or
misinterpreting some basic point. But after several days and reads of
the DIP, I still feel the same and nobody seems to address the issue; so
here I go. Excuse the noise if I'm simply wrong. I feel ashamed to send
that -- but let's be bold :-).]
Thanks for the input, but you are missing several very important points:
1. toString will not be made 'illegal', you can still write toString
methods and use them as you wish (writing a toString method without also
writing a writeTo method will be deprecated for a time, but after that the
compiler will not complain). But writeln, format, to!string, etc. will
not use them.
2. toString can unequivocally be replaced anywhere you see it with
to!string. There is zero loss of functionality, and the change is not
unpleasant. Not only that, but almost *no* code uses toString, it is more
correct to use to!string, and let to!string make the right decision. The
reason is because to!string handles builtin types (which have no toString
member), and custom structs without a toString member. You should never
have to write a delegate to pass to writeTo directly unless you have some
funky way of outputting the data, but in that case, writeTo is better for
you anyways.
3. Yes, toString could support an optional formatting argument, but that
is not my main concern (it is Don's and others, I'm assuming you too). My
main concern is that in order to hook into writeln, format, to!string,
etc, your type *must* define a function that necessarily allocates
memory. writeTo not only solves that problem, but in most cases does not
change the difficulty of converting objects/structs to text format (and in
many cases, it simplifies the code which creates the string).
-Steve
