The demise of T[new]

[Johan Granberg]

Andrei Alexandrescu wrote:

> Leandro Lucarella wrote:
>> Andrei Alexandrescu, el 19 de octubre a las 10:18 me escribiste:
>>>> 2 types should be provided: array and slice.
>>>>
>>>> array is a *real* type, storing and owning memory, it should be
>>>> something like this (conceptually):
>>>>
>>>> class array(T)
>>>> {
>>>> size_t length;
>>>> size_t capacity;
>>>> T[capacity] elements;
>>>> }
>>> At the point I introduce arrays I hadn't described classes.
>> 
>> You are talking about the book, right? You don't have to! You can explain
>> arrays without talking about classes at all!
> 
> I was just replying to your suggestion.
> 
>>> One major problem with writing a "The X Programming Language" book
>>> is sequencing. It's very easy to explain a complicated feature if
>>> the listener knows all others. It is very difficult to introduce
>>> them serially.
>> 
>> I don't think an array would be the case, come on! =)
>> 
>>>> 1) a pure reference type.
>>>> 2) 1 allocation only (interior pointers are not a problem, the GC have
>>>> to
>>>>   support them anyways).
>>>> 3) easily appendable (capacity field).
>>>>
>>>> slice should be something like this:
>>>>
>>>> struct slice(T)
>>>> {
>>>> size_t length;
>>>> T* ptr;
>>>> }
>>> structs and pointers have also not been introduced yet.
>> 
>> I don't know what this have to do with the book. Should be D designed
>> based on how good are you to explain the concepts on the book?  I think
>> this is getting ridiculous... seriously. I don't want to be rude, I know
>> you're putting a lot of work in the book and we all appreciate that, but
>> you didn't mention any technical point about what I wrote.
>> 
>>>> I'm missing something? Why this shouldn't work?
>>> It may work, but I was unable to pull it off reasonably well.
>> 
>> What problems did you find?
> 
> I thought I explained that above and in several other posts. I have the
> feeling this is going in circles, but let me add one more thing. People
> would want to have a reasonable way of choosing between T[new] and T[].
> The differences between them are subtle (I have two tables showing the
> primitives of T[] and T[new], which are very similar). That static
> decision concerns future appends to the array, which doesn't strike me
> as something you know from the get-go through future iterations of a
> design. Use of "auto" messes up things further: a nice function may
> choose to return T[new] because it just created an array (an
> implementation detail), but clients may find that unexpected.
> 
> 
> Andrei

I think you are seeing a larger problem than their is. But consider this,
who is D a language for, is it for beginers only? advanced users only? or
everyone, if it is a language for everyone don't complicate the language
for the advanced users by rejecting nice syntax just because it is hard to
explain. The beginers already will just pick one and write ineficient code
and I don't think one more type will manage to confuse them more (as most
beginers I thaught is already maximaly confused).