COW vs. in-place.

[Oskar Linde]

Dave wrote:
> Oskar Linde wrote:
>>
>> 1. in-place default, copying algorithms specially named
>> -------------------------------------------------------
>>
>> Design:
>> void toUpper(char[] str); // in-place
>> char[] toUpperCopy(char[] str); // copy
>>
>> Pros:
>> * in-place is often more efficient and therefore default.
>> * many functions are imperative verbs, and as such one expects them to 
>> be modifying
>> * Similar to how the C++ STL is designed
>> Cons:
>> * many functions can not be expressed in-place (example: UTF-8 toUpper)
>>
> 
> Hmmm - Is the current implementation of std.string.toupper wrong then?

Not really. Some of the newer case folding mappings from Unicode are 
missing from std.uni, so it could be better though.

> (If you removed the if(!changed) {...} blocks [where the CoW is milked] 
> you would effectively have an in-place implementation).

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.

>>
>> 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. ;)

>> * in-place is an optimization and would stand out as such
> 
> It's only considered an 'optimization' right now because it's different 
> from the default (CoW).
> 
>> * default is functional (no-side effects), side effects stand out
>> * people used to functional style programming would not find any
>> surprises
>> * all functions can be defined as copying functions
>> * how many popular languages are designed (Ruby, Python, php, all 
>> "functional" languages, etc...)
> 
> Yes, but all of these are languages where performance is not an 
> imperative (excepting some of the functional languages perhaps). Plus 
> think of all the time and effort that have been spent on GC's because of 
> this design choice :)
> 
>> Cons:
>> * could confuse people, lead to silent errors:
>> toupper(str); // doesn't change str
>> cos(x); // doesn't change x ;)
>>
>> For the record, I am in favor of number 2 and that would have biased 
>> the arguments above.
> 
> Likewise I'm in favor of #1 ;)

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.

/Oskar