eliminate new operator paraphernalia

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Sun Feb 14 14:32:48 PST 2010


Kasumi Hanazuki wrote:
>> 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.

Perfect. Thank you Kasumi-san.

Andrei



More information about the Digitalmars-d mailing list