eliminate new operator paraphernalia

Kasumi Hanazuki k.hanazuki at gmail.com
Sun Feb 14 14:27:26 PST 2010


> I suggest the following syntaxes for a type T, an integral length, an
> initializerlist a la "e1, e2, e3, ..." that could be empty, and an addr
> convertible to void*:
>
> new T[length]
> new T(initializerlist)

This may be a bit off-topic, but now is the chance to think about the
array-new'ing syntax...

Currently, D has two syntaxes to allocate a dynamic array (type of T[]),

- new int[n]; // n can be a non-constant
- new int[](n);

and no way to allocate a static array (type of T[N]) dynamically.

- new int[3]; // this is not an int[3] but a int[]
- alias int[3] int3;
   new int3; // this is not allowed!

I think it is inconsistent in following points:

- {new int[1][2][3]} allocates an int[1][2][] of length 3
   (only the last parameter has the different meaning).
- {new int[3]} and {new int3} behave differently as shown above.

So I suggest that
- {new T[N]} would accept only a compile-time constant as N and
   allocate a T[N] as if T[N] were a struct type.
- {new T[](n)} would allocate a T[] of length n as if T[] were a class
   type and had a constructor taking one size_t parameter
   (same as current implementation).

With this semantics, {new int[2][3]} shall allocate an int[2][3],
{new int[2][](3)} an int[2][] of length 3, {new int[][](2, 3)}
an int[][] of length 3 having three int[] of length 2 as its elements.



More information about the Digitalmars-d mailing list