constness for arrays

[Andrew Fedoniouk]

"Don Clugston" <dac at nospam.com.au> wrote in message 
news:e9nvee$2h4m$1 at digitaldaemon.com...
> xs0 wrote:
>> Craig Black wrote:
>>> Sounds like a great idea to me.  Easy to implement, improves correctness 
>>> and performance.  What are we waiting for?
>>
>> Personally, I'm waiting/hoping for Walter to see the proposal and say 
>> what he thinks :)
>>
>> I'm also wondering whether the "overwhelming" response to the proposal is 
>> because
>> - I didn't write "proposal" in the subject
>> - it's from me (I used to argue in a bad way too much, I'm sure I'm being 
>> filtered at least by some people :)
>> - it's so bad it's not even worth a comment
>> - it's so good everybody is already waiting for Walter to say yes ;)
>
> Maybe you just need some better terminology. How about
>
> arr.clone
> to replace arr with a writable copy of arr (instead of "needToWrite").
> (you don't care if its the original arr, or a dup)
> and turn it into a proposal about a more efficient dup.
>
> Modify Only One Copy On Write.
> (MOO COW).
> <g>.

Don, I think that reference counting (MOO COW) has the
same set of "civil rights" as GC so probably it makes sense
to look on this from language design perspective in more universal
fashion. RefCounting of arrays is only one particular thing I mean -
language shall support this idiom with the same quality as GC.

In fact for typical and effective refcounting implementation it is
enough to have ctors/dtors/assignement in structs.
Having them MOO COW can be implemented easily without
need of runtime model changes.

And MOO COW is somehow orthogonal to constness.

Again, I would try to find here more universal solution
rather than particular array problem.

I beleive that "smart pointer" as an entity will cover
MOO COW cases. But D does not have facilities
now for smart pointers at all.


Andrew Fedoniouk.
http://terrainformatica.com