Semantics of toString

[Don]

Bill Baxter wrote:
> On Tue, Nov 10, 2009 at 4:40 AM, Don <nospam at nospam.com> wrote:
>> Lutger wrote:
>>> Don wrote:
>>> ...
>>>> There is a definite use for such as thing. But the existing toString()
>>>> is much, much worse than useless. People think you can do something with
>>>> it, but you can't.
>>>> eg, people have asked for BigInt to support toString(). That is an
>>>> over-my-dead-body.
>>> Since you are in the know and probably the biggest toString() hater
>>> around: are there plans (or rejections thereof) to change toString() before
>>> D2 turns gold? Seems to me it could break quite some code.
>>
>> I'm hoping someone will come up with a design.
>>
>> Straw man:
>>
>> void toString(void delegate(const(char)[]) sink, string fmt) {
>>
>> // fmt holds the format string from writefln/formatln.
>> // call sink() to print partial results.
>>
>> }
> 
> That looks pretty good, actually.
> I guess I would like to see plain no-arg toString() still supported.

The thing is, the toString() function is essentially a virtual function 
present in every struct. Each one of those functions needs a very strong 
justification to exist.

> A default toString() could be implemented in terms of the fancy one as:
> 
> string toString() {
>      char buf[];
>      toString( (string s) { buf ~= s; }, "" );
>      return assumeUnique!(buf);
> }
> 
> could be a mixin in a library I suppose.

More for the benefit of consumers, or producers?

Because
void toString(void delegate(const(char)[]) sink, string fmt) {
    sink("xxx");
}
isn't much more complex than:
string toString()
{
   return "xxx";
}
other than the signature.


> 
> I think I would like to see the format strings not necessarily tied to
> writefln's particular format.

I think the format strings are actually pretty similar, Tango vs 
writefln? There might be enough common ground. I think the Tango format 
is a slight superset of the writefln one.