COW vs. in-place.

[Reiner Pope]

Dave wrote:
> Reiner Pope wrote:
>>> Why not:
>>>
>>>     str = toupper(str);     // in-place
>>>     str = toupper(str.dup); // COW
>>
>> This is not copy on write. That is simply 'always copy', and this 
> 
> But presumably the user would only do the dup if they didn't want to 
> modify str, so CoW would basically go away as a design pattern.
> 
>> performs worse than COW (which in turn performs worse than in-place, 
>> if in-place is possible). Walter has also said earlier that, with COW, 
>> it should be the responsibility of the writer to ensure the copy, not 
>> the caller.
> 
> That's what I'm questioning ultimately. The caller knows best if the 
> object that _they created_ should be modified or copied and they can do 
> that best before a call to a modifying function. No matter if that 
> happens to be the developer of another lib. function or an application 
> programmer.
> 
> What's more, CoW for arrays is inconsistent with how other reference 
> objects are treated (class objects are really not made for CoW - there's 
> not even a rudimentary copy ctor provided by the language. Same with 
> AA's, which don't have a .dup for example).
> 
> Ultimately, most data that is modified is used modified for its 
> remaining program "lifetime", and however the original data was sourced 
> (e.g.: reading from disk) can be replicated if needed instead of having 
> to keep copies around.
> 
> I think CoW for arrays was a mistake -- it is most often unnecessary, 
> will cause D to repeat many of Java's performance woes for the average 
> user, and as I mentioned is inconsistent as well. It's a lose-lose-lose.
> 
> - Dave
While I'm not convinced that CoW is such a bad situation, I agree with 
you that it is not perfect. However, a proper solution would need to 
make use of some facts:
  - the caller knows best whether the array may be edited in-place
  - whether the string should be modified in-place is often not known at 
compile time.
These require the passing of a bool indicating whether it should be 
copied on write, or not, which is just as you suggest.

However, to support this with the nicest code, it would be best to be 
both compiler-checked and language-supported. Of course, this is just 
advertising for the rocheck type modifier I'm proposing in YACP. The 
benefit of language support can also mean that inlining in situations 
with readonlyness known at compile time may have the CoW checking 
optimized away.

Cheers,

Reiner