Replacing new? (was re: -nogc)

[Andrei Alexandrescu]

Daniel Keep wrote:
> 
> Andrei Alexandrescu wrote:
>> Joel C. Salomon wrote:
>>> Just as (1) & (2) point to a way to remove the “magic” of built-in
>>> arrays & hash-tables, so too might (5) & (6) point to a way of replacing
>>> the “new T(args)” syntax with something cleaner?  Not that
>>> “new!(T)(args)” looks nicer than the current syntax, but is it perhaps a
>>> better fit with the rest of the language?
>> I agree. new sucks.
>>
>> Andrei
> 
> Oh I don't know, I rather like being able to allocate stuff on the heap.
>  I mean, if I didn't, the poor heap would probably be very lonely.
> 
> Poor, poor oft-maligned heap; all because he's a bit slower than stack
> allocation and needs to be cleaned up after.  He's trying to help, you know!
> 
> Joking aside, what do you have in mind?  Every solution I come up with
> ends up being more or less the same (except with the 'new' keyword in a
> different place) or worse.

I don't know. Here's what we need:

1. Create one heap object of type T with creation arguments args. 
Currently: new T(args), except when T is a variable-sized array in which 
case syntax is new T[arg] (only one arg allowed). It is next to 
impossible to create one heap object of fixed-size array type.

2. Create one array T[] of size s and initialize its elements from a 
range or generator function. Currently possible via a function that 
internally uses GC calls.

3. Create one array T[] of a size s and do not initialize content. 
Currently possible by calling GC functions. Probably not really needed 
because it's not that safe anyway.



Andrei