Semantics of toString

[Andrei Alexandrescu]

Denis Koroskin wrote:
> On Wed, 11 Nov 2009 04:27:45 +0300, Andrei Alexandrescu 
> <SeeWebsiteForEmail at erdani.org> wrote:
> 
>> Bill Baxter wrote:
>>> 2009/11/10 Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>:
>>>> Denis Koroskin wrote:
>>>>> On Wed, 11 Nov 2009 02:49:54 +0300, Andrei Alexandrescu
>>>>> <SeeWebsiteForEmail at erdani.org> wrote:
>>>>>
>>>>>> Don 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.
>>>>>>>  }
>>>>>> I think the best option for toString is to take an output range 
>>>>>> and write
>>>>>> to it. (The sink is a simplified range.)
>>>>>>
>>>>>> Andrei
>>>>> It means toString() must be either a template, or accept an abstract
>>>>> InputRange interface?
>>>> It should take an interface.
>>>  So yet another type in object.d?
>>> Or require users in import something specific in every module that's
>>> going to use toString?
>>>  --bb
>>
>> I am not sure. Opinions as always are welcome.
>>
>> Andrei
> 
> Some ranges may be polymorphic, so having base interface hierarchy in 
> Phobos would be useful anyway.
> 
> BTW, save() is already implemented and used throughout the Phobos under 
> a different name - opSlice (i.e. auto copy = range[]). It's a bikeshed 
> discussion, but why save() and not opSlice(), or even clone()?

It can't be clone() because it doesn't clone. For example say you have a 
T[] - one would expect clone() actually copies the content. But using 
opSlice is a good idea.

Andrei