What's wrong with just a runtime-checked const?

[xs0]

> Ah, I understand the objective now.
> 
> But then, this problem you are trying to solve here is one of 
> performance only, related to ownership management, but not necessarily 
> the same. In particular:

> * Whatever mechanism is made to deal with that problem, cannot be 
> disabled in release builds: it is not a contract, unlike const/ownership 
> checking which is a contract, and being so can be checked at compile 
> time, or at runtime in debug releases only.

Well, it is a contract (though shall not modify a readonly array), just 
not verifiable at compile-time. Similar to in{} and out{} blocks, I 
guess.. It has other (potentially significant) benefits, though..

> * For that same reasons, such mechanism should not be a substitute for 
> const/ownership checking, since this latter one can be processed at 
> compile time, which is naturally more efficient, and the former one can't.

I disagree about efficiency - it turns out there is negligible speed 
impact even if .readonly is not used at all, while it can be used for 
significant speed improvements with simpler code (in particular, writing 
a fast and safe COW function is easier). I posted test results and code 
in digitalmars.D, if you're interested (I think :)

> * Such mechanism is likely impractical or too hard to implement in the 
> general sense (that is, for any data type). So perhaps the mechanism 
> should be implement not by the language/compiler, but by the coder with 
> existing language constructs (mixins, etc.)?

Well, you could code your own array references (like I did for my test), 
but they lose on ease of use and are less flexible in general (because 
you can't code an inheritance tree which would mimic the built-in 
arrays'). On the other hand, if it was language-supported, nothing would 
be lost, and something would be gained..


xs0