constness for arrays

[xs0]

Andrew Fedoniouk wrote:
> Dynamic constness versus static (compile time) constness is not new.

Never said it was.

> For example in Ruby you can dynamicly declare object/array readonly and
> its runtime will control all modifications and note - in full as Ruby's 
> sandbox
> (as any other VM based runtime) has all facilities to fully control
> immutability of such objects.

Cool! OTOH, I'm proposing of making the reference readonly, not the data 
itself.


> In case of runtimes like D (natively compileable) such control is not an
> option.

Because?


> I beleive that proposed runtime flag a) is not a constness in any sense

It's more like readonlyness.

> b) does not solve compile verification of readonlyness and

I said so myself :P But, the question is whether compile-time 
verification is better or not. In some cases it definitely isn't;

int[] cowFoo(int[] a) { if (whatever) { a=a.dup; a[0] = 5; } }
int[] cowBar(int[] a) { if (something) { a=a.dup; a[1] = 10; } }

int[] result=cowFoo(cowBar(whatever));

How can a compile-time check ever help you avoid the (unnecessary) 
second .dup when both funcs decide to modify the data?

> c) can be implemented now by defining:
> struct vector
> {
>     bool readonly;
>     T*  data;
>     uint length;
> }

So? How does that help when using built-in arrays?

> Declarative contness prevents data misuse at compile time
> when runtime constness moves problem into execution time
> when is a) too late to do anything and b) expensive.

I disagree. A single .dup probably costs more than tens (if not 
hundreds) of checks of a single bit (which can even be disabled in 
release builds). And why would it be too late to do anything?

> I would mention old idea again - real solution would be in creating of
> mechanism of disabling exiting or creating new opertaions
> for intrinsic types.

Start your own thread :P


xs0