Dynamic array creation with default

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Tue Aug 23 13:32:31 PDT 2011


On 8/23/11 12:32 PM, Don wrote:
> foobar wrote:
>> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s
>> article
>>> On 8/23/11 6:15 AM, foobar wrote:
>>>> == Quote from bearophile (bearophileHUGS at lycos.com)'s article
>>>>> foobar:
>>>>>> you raise a valid concern but this looks too complicated.
>>>>>> I'd suggest to simplify into only two cases.
>>>>>>
>>>>>> // 1) T.INIT - as you suggested the dimension should be checked
>>>>>> auto foo = new int[][](10, 20); // correct
>>>>>> auto foo1 = new int[][](10); // compilation error
>>>>> Keep in mind that currently this is correct and it generates a 1D
>>>>> dynamic array:
>>>>> auto v = new int[10];
>>>> Isn't this an inconsistency in the language?
>>>>
>>>> // Generally speaking, allocates an instance of T on the heap
>>>> auto foo = new T;
>>>>
>>>> However, "int[10]" and "new int[10]" are different types.
>>> I hate that, too. Walter hates it, too, but we both reckon it's too late
>>> now to change things. It makes it impossible to create an instance of
>>> the type "int[10]" dynamically because of an gratuitous syntactic
>>> special case. It comes from C++, where it was an unforced error.
>>> Andrei
>>
>> Is it possible to deprecate/disallow "new T[size]" since we have an
>> alternate
>> syntax for it? At least until D3 comes along when we could change
>> this. This also
>> aligns with your goal of moving built-in types from the
>> compiler/runtime to the
>> library (AAs..) which I think is an important goal.
>> I'd like to see dynamic arrays as well as AAs as plain templates in
>> phobos and D
>> itself only provides a thin layer of syntax sugar for literals and such.
>
> Please note that moving AAs from built-in to library was little short of
> a disaster, as far as the compiler is concerned. It created a horrific
> number of regression bugs (more than 20% of all serious regressions have
> been caused by it), it's occupied months of time, the job is still only
> half done, and as far as I can see, there's actually been ZERO benefit
> from it.

We're not seeing benefits because they haven't materialized yet; the 
benefit so far is that it paves the way toward finalizing the 
transition. But point taken about the difficulties.

Andrei


More information about the Digitalmars-d mailing list