resizeable arrays: T[new]

[Walter Bright]

Derek Parnell wrote:
> On Mon, 04 Jun 2007 02:33:58 -0700, Walter Bright wrote:
> 
>> ... 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
>>
>>     a.length = 6;   // error, static array
>>     b.length = 6;   // error, dynamic array is not resizeable
>>     c.length = 6;   // ok
> 
> Huh? 'static array' used to mean fixed-size array

It still does.

> and 'dynamic array' used
> to mean 'variable-length array' ... so a dynamic array is not dynamic
> anymore?

A dynamic array would now mean that its length is not known at compile time.

> So a dynamic array is 'sizeable' but not 'resizable'. In other words, once
> its length has been set it can never be changed again? Is that what you are
> saying?

Yes.

> And is that a compile-time or a run-time check?

Compile time.

> If this is what 'resizeable' means for dynamic arrays then nearly all my
> dynamic arrays will have to be changed to resizable ones, because I rely on
> that feature for lots of things. 

Without looking at your code, I suspect it may be less than you think. I 
thought I was modifying strings all the time, so when switching over to 
const strings, I expected lots and lots of work. Turns out, only rarely 
do I do this.


> What is the point of having dynmaic arrays now? The difference between them
> an static arrays is rather small.

Consider the following:

	alias char[] string;

That alone justifies it! And the difference between static arrays and 
dynamic arrays is very large. For one thing, static arrays are passed by 
value, and dynamic arrays by reference.

>>     b = c;          // ok, implicit conversion of resizeable to dynamic
> 
> But hang on, you said that b.length isn't allowed to change? Or did you
> mean that it can only change if b.ptr also being updated?

I meant that the underlying array cannot be resized through b. b itself 
can have its ptr/length values changed through simple assignment, but 
there will be no realloc happening.

>> I think this will entail only very rare changes to user code, but will 
>> be a big improvement in type safety. 
> 
> Not so sure about that ... I'll do some analysis and report back.
>