COW vs. in-place.

[Dave]

Oskar Linde wrote:
> Dave wrote:
> 
> Again, not really. :) See Thomas Kuehne's post further up the thread. 
> There are certain unicode case foldings where the number of UTF-8 
> element changes. This will be handled correctly by 
> std.string.toupper/tolower, but the result can not be in-place.
> 

Not (pedantically) in-place for those cases, but for all cases you could still get around a complete 
.dup (and of course the string arguments would have to change to be passed inout for to/upper/lower, 
std.uni.encode, etc.).

>>>
>>> 2. copying default, in-place versions specially named
>>> -----------------------------------------------------
>>>
>>> Design:
>>> void toUpperInPlace(char[] str); // in-place
>>> char[] toUpper(char[] str); // copy
>>>
>>> Pros:
>>> * copying is safer, and is therefore a better default
>>
>> Only if the coder expects that is the default, *and* they most often 
>> need the original data intact later in the program.
>>
>> And that safety is not much of an advantage when your code is 
>> three-legged dog slow and eats up resources that could be used by 
>> other processes :) Walking to work may be safer than going 70 MPH on 
>> the freeway, but it would take me a week and I'd starve.
> 
> Is someone prejudiced here? :) I could counter that with how functional 
> style programming is superior in all other ways, but I won't. ;)
> 

I didn't intend it that way <g> Just pointing out that I'm not overly concerned with complete safety 
with a language like D when it can cost a lot.

> I could live with either one. It is after all only a matter of naming. 
> Consistency is the most important thing. The argument that there are 
> only a small subset of all functions for which in-place as a concept is 
> applicable is IMHO quite strong.

You're right, it is a very small subset in Phobos right now but 'CoW' seems to be the design pattern 
chosen for D. As this thread went on I became concerned that CoW for arrays is probably not the way 
to go for a language like D (all IMHO).

> 
> /Oskar