Walter: Before you go and implement the new RAII syntax..

[Brad Roberts]

Chad J wrote:
> Jarrett Billingsley wrote:
>> This is what I'm talking about:
>>
>> Foo f = Foo(); // RAII
>> Foo g = new Foo(); // Normal
>>
>> Can we all discuss this?  I'm sorry, but that syntax is just too easy 
>> to mess up / miss.  I'm surprised that you, someone who is very much 
>> against "secret things happening" would be a proponent of this 
>> syntax.  It's just too nonobvious.  (And as a minor point, this also 
>> makes it impossible to make a static opCall with a class.)
>>
>> How about instead, we keep auto to mean a RAII reference, and we take 
>> the C# route for type inference and come up with a "var" keyword which 
>> would be a "type placeholder".  That is:
>>
>> var f = new Foo(); // Normal
>> auto var g = new Foo(); // RAII
>>
>> And as you can see, this gets rid of thee "auto auto" problem.  Not to 
>> mention it gets rid of the very common misunderstanding that 
>> currently, "auto" is somehow used for type inference, when in fact 
>> it's simply the use of a storage class without a type that invokes 
>> type inference.
>>
>> This, or maybe we could use a "stack" or "local" or "raii" keyword in 
>> place of the "new":
>>
>> Foo f = stack Foo();
>> Foo g = local Foo();
>> Foo h = raii Foo();
>>
>> Something.  Anything would be better than the "new or nothing" syntax.
>>
> 
> I agree.
> 
> It also makes sense to me to use various keywords to determine what kind 
> of allocation is done:
> 
> Foo a = new   Foo(); // compiler optimized allocation
> Foo b = heap  Foo(); // allocate on heap
> Foo c = stack Foo(); // allocate on stack
> Foo d = scope Foo(); // raii
> 
> Also, it may be wise to make the keyword prefix the lvalue rather than 
> be the allocator, for a reason I saw pointed out by Bruno Medeiros in a 
> previous discussion:
> 
> You can't make auto objects out of objects allocated with a function
> (like a factory method) instead of inline allocation. For example, the
> following cannot be made with a no-allocator-keyword syntax:
>   auto Foo foo = SomeFactory.newFoo(..); // can't make an auto here
>   auto char[] a = read(filename); // can't make an auto here
> 
> ... so we'd have
> scope Foo f = new Foo();
> and I don't know why anyone would want to, but someday you could
> scope Foo f = heap Foo();

Specifying storage mechanism seems like unnecessary compiler 
hamstringing.  Specify behavior and give the compiler authors the 
freedom to detect and optimize the storage.  See previous discussions on 
escape analysis.

Ages ago it was realized in the C language and descendants that the 
'register' keyword was pointless and, as far as I know, no compiler 
today obeys it.  Let's not repeat that misfeature.

Later,
Brad