Replacing new? (was re: -nogc)

[Daniel Keep]

Andrei Alexandrescu wrote:
> 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.

Actually,

> new T[](size);

This works just fine.  I do think that (new T[n]) should be of type
T[n], not T[].

> 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

Perhaps have these overloads for object.Array!(T)...

> new T[](size_t, T)
> new T[](size_t, S) if isInputRange!(S)

As for the uninitialised case, I don't think it's that important, either.

<dreaming>

That said...

Assuming I'm allowed to make language changes, I'd be tempted to make
void a valid type for variables and arguments, and also make it double
as an expression.  That is, void is a literal of type void with value
void, the ONLY valid value for voids.  Then, you could have:

> auto a = new T[](n, void);

I've always been annoyed that you can't have void variables or
arguments; it always seems to complicate my beautiful generic code :'(

> ReturnTypeOf!(Fn) wrap(alias Fn)(ParameterTypeTuple!(Fn) args)
> {
>     logf("> ",Fn.stringof,args);
>     auto result = Fn(args);
>     logf("< ",Fn.stringof,args);
> }

That works only so long as Fn doesn't return a void.  And before anyone
suggests it, this trick:

> return Fn(args);

only works in trivial cases; it doesn't help if you need to be able to
DO something after the function call.

</dreaming>

  -- Daniel