suggestion: read-only array-reference

[Hasan Aljudy]

xs0 wrote:
> Hasan Aljudy wrote:
> 
>  > [snip]
> 
> First, let me just say I'm all for compile-time verification as much as 
> possible.
> 
> But, your proposal has a problem - it introduces an entirely new type. 

heheh, the suggestion *is* introducing a new type; that's the whole point.

> You still can't write one function for both readonly and mutable arrays.
Yes you can. Why do you say you can't?

> You still can't know if you need to COW or not.
Sure you do.
If you're using read-only reference then you don't need to worry about 
COW because it's enforced by the compiler.
If you're using a normal array reference, then you either don't care 
about COW or you made a mistake.

> As soon as a function 
> takes a readonly parameter, all the functions it calls in turn also need 
> to be declared readonly..

Yes, that's true.
For this suggestion to work practically, all phobos functions must be 
re-touched to take read only array references.
(I said "re-touched" instead of saying "re-written", because COW is 
already implemented in phobos, so changing the type of parameters 
shouldn't break anything.)

The same probably applies for other libraries.

However, on the other hand, most of the times you really only need 
read-only references.
This is the case with Java. There are two types of strings, String 
(immutable/read-only interface) and StringBuffer (mutable/read-write 
interface).
Most of the time, you deal with String rather than StringBuffer.
So we're not "experimenting" with something that's totally new. It's 
been done before, and it seems to be doing just fine.

> 
> At the cost of some verbosity, the same effect can already be achieved 
> with a simple array wrapper...
Yes, it could, and I think that's interesting, because even though there 
are ways to eforce compile-time immutability for arrays and even 
classes, people still cry for C++-style constness.

However, think about it from a library-writer prespective. Should you 
make such a class yourself? What if other library writers provided 
different classes to achieve the same effect?
These different classes would be incompatible with each other, making it 
very hard to use such libraries together seamlessly.

Having a standarized wrapper is better. It could either be implemented 
in Phobos, or as a builtin type.
I think having it as a builtin type would make things simpler, and it 
seems to fit with D's philosophy of having certain things built-into the 
language rather than implemented as a class.

After all, D has dynamic arrays builtin, associative arrays builtin, 
complex numbers built in, etc.

Having a builtin read-only array reference would serve to encourage 
using it.
Additionally, we can use the same rational for builtins that Walter used 
for other things: having this built-in means that the compiler knows 
about the read-only array idiom, and can provide meaningful error 
messeges and prevent any possible attempt to break the contract (using 
asm or whatever pointer tricks available).