resizeable arrays: T[new]

[Sean Kelly]

Walter Bright wrote:
> 
> (The problem is if I pass a slice to a function, and then that function 
> reallocates the slice by changing the length or appending to it, it can 
> affect other slices into the same data in very hard-to-explain ways.

I'm not sure I understand how a reallocation could affect other slices 
into the same data.  If a reallocation occurs, that reallocation will be 
into entirely new memory, provided the slice doesn't start at the head 
of a memory block.  Is it the condition I just mentioned that's a 
problem?  If so, I suppose it is one way to trick the compiler into 
thinking the reference no longer refers to const data, when in fact it 
does.  If not, could you point me in the right direction?

> Now, it turns out that it is very rare for a function to legitimately 
> want to resize a buffer passed to it. So we finally hit on the idea of 
> making a resizeable array a different type, say:
> 
>    T[n]   a;  // static array
>    T[]    b;  // dynamic array
>    T[new] c;  // resizeable array

Well, I think it is very rare for a function to want to resize an array 
that isn't passed by reference.  My first reaction would be to disallow 
resizing of non-ref array parameters entirely.  Since resizing may occur 
in place, this could be seen as a mutating operation on the underlying 
data.  If the user wants to resize a non-ref array parameter for local 
use he use assign ops and such.

I think this may be related to a question I've been avoiding until now: 
how will the new const features interact with struct and class member 
function use?  Will it always be legal to call member functions of const 
objects?  Will it never be legal?  Or perhaps there will be a way to 
label some operations as non-modifying (which suggests logical const)?


Sean