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