The demise of T[new]

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Mon Oct 19 08:18:22 PDT 2009


Leandro Lucarella wrote:
> Andrei Alexandrescu, el 18 de octubre a las 20:16 me escribiste:
>> Here's what I wrote to Walter:
>>
>> ====================
>> I'm going to suggest something terrible - let's get rid of T[new]. I
>> know it's difficult to throw away work you've already done, but
>> really things with T[new] start to look like a Pyrrhic victory. Here
>> are some issues:
>>
>> * The abstraction doesn't seem to come off as crisp and clean as we
>> both wanted;
>>
>> * There are efficiency issues, such as the two allocations that you
>> valiantly tried to eliminate in a subset of cases;
>>
>> * Explaining two very similar but subtly different types to
>> newcomers is excruciatingly difficult (I'll send you a draft of the
>> chapter - it looks like a burn victim who didn't make it);
>>
>> * Furthermore, explaining people when to use one vs. the other is
>> much more difficult than it seems. On the surface, it goes like
>> this: "If you need to append stuff, use T[new]. If not, use T[]."
>> Reality is much more subtle. For one thing, T[new] does not allow
>> contraction from the left, whereas T[] does. That puts T[] at an
>> advantage. So if you want to append stuff and also contract from the
>> left, there's nothing our abstractions can help you with.
> 
> I think this is getting overcomplicated. I don't see it as complex, I see
> it like this:
> 
> 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.

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.

> 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'm missing something? Why this shouldn't work?

It may work, but I was unable to pull it off reasonably well.


Andrei



More information about the Digitalmars-d mailing list