On Sun, 09 Aug 2009 16:29:21 -0400, Walter Bright
<[email protected]> wrote:
D has a number of subtle problems (performance and semantic) that arise
when arrays are resized. The solution is to separate resizeable array
types from slices. Slices will retain the old:
T[] slice;
syntax. Resizeable arrays will be declared as:
T[new] array;
The new expression:
new T[10]
will return a T[new].
T[new] will implicitly convert to T[], but not the other way.
slice.length will become read-only.
Under the hood, a T[new] will be a single pointer to a library defined
type. This library defined type will likely contain three properties:
size_t length;
T* ptr;
size_t capacity;
The usual array operations will work on T[new] as well as T[].
Doing this change will:
1. fix many nasties at the edges of array semantics
2. make arrays implementable on .net
3. make clear in function signatures if the function can resize the
array or not
Yay!
Will capacity be settable? That is, can I replace this pattern:
char[] buf = new buf[1024];
buf.length = 0;
with something like this?:
char[new] buf;
buf.capacity = 1024; // ensure capacity is *at least* 1024
----
I read elsewhere that
T[new] x;
doesn't allocate until length (or maybe capacity) is non-zero.
So T[new] is a library defined type. What does the underlying type get
called with when x.length = 5 is entered? Is the underlying type:
1. an object?
2. a templated type?
----
What happens when you do:
x = null;
where x is a T[new] type?
Is it the same as setting x.length = 0, or x.capacity = 0?
What does x == null mean? What about x is null?
Will ptr be settable, or only readable?
Will the compiler continue to optimize foreach calls to arrays? How will
foreach be implemented, as a range or opApply? The former implies some
automated method to return a range, because you wouldn't want to modify
the referenced array during iteration.
This is exciting :)
-Steve
