Semantics of toString

[Denis Koroskin]

On Wed, 11 Nov 2009 18:50:47 +0300, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> 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

Well, range doesn't own any of the contents it covers, so deep copy is  
impossible.
Yet, there is also .dup array property which is pretends to be a standard  
way of creating instance copies.