Replacing new? (was re: -nogc)

[Denis Koroskin]

On Fri, 24 Apr 2009 08:47:49 +0400, Daniel Keep <daniel.keep.lists at gmail.com> wrote:

>
>
> 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)
>

I agree these overloads belong to Array.

> 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);
>

This is a nice idea!

> 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);
       return result;
>> }
>
> 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

Yes, I've hit the same issue a lot of times, although scope(exit)/scope(success) usually helps.