unsafe toString() behavior

[kris]

Chris Miller wrote:
> On Tue, 27 Jun 2006 00:44:05 -0400, BCS <BCS_member at pathlink.com> wrote:
> 
>> In article <op.tbr0mdsfpo9bzi at moe>, Chris Miller says...
>>
>>>
>>> On Mon, 26 Jun 2006 19:18:15 -0400, lenfestey at geemail.com  =
>>>
>>> <lenfestey_member at pathlink.com> wrote:
>>>
>>>> import std.stdio;
>>>> import std.string;
>>>>
>>>> void main() {
>>>> char[] x =3D toString(0);
>>>>
>>>> // la de da...
>>>> x[0] =3D 'a';
>>>>
>>>> // guess what i print
>>>> writefln("x=3D%s", toString(0));
>>>> }
>>>>
>>>> It is because toString(uint) sometimes returns an array slice.
>>>>
>>>> Aaron Lenfestey
>>>
>>>
>>> In D you have to practice COW (copy-on-write) unless you are certain you
>>> are the only one using the memory.
>>
>>
>> IM(h)O toString should *always* return a copy.
>>
> 
> Nah, I disagree. Take MemoryStream for example, what if it has 2MB, you  
> want that copied every toString. This COW is just a different method 
> than  what's common in other languages, and yields such a great 
> performance  boost. If you want a copy, copy it. But if all you want to 
> do is read the  value, what is the point in copying.
> 
> Plus, where does this copying stop? Should every function returning an  
> array, or even a reference, make sure the caller gets a copy he can modify?
> 
> However, I think I would be in favor of some type of immutability,  
> provided it isn't so wordy and troublesome as C/C++'s.

Hear Hear! ;)

Even if the immutable aspect could be supported for return-values only, 
we could then wrap our valuable immutables within an aggregate for those 
cases where immutability can be a considerable help (e.g. multi-threaded 
information sharing).

That approach (return-values only) may be naiive on my part ~ would it 
notably simplify things in terms of implementation detail?