auto, var, raii,scope, banana

[Chad J]

Regan Heath wrote:
> 
> 
> I say lets keep 'auto' for auto type inference (for the reasons you and  
> Don mention)
> 
> I like the use of scope at class decl. But, I prefer the no keyword  
> approach at instantiation. So, allow me to suggest this as a 3rd option.
> 
> - 'scope' at class decl.
> - no keyword at instatiation.
> 
> Reasoning:
> 
> 'new' implies heap allocation to me. It would be beneficial to allow 
> the  compiler to allocate an RAII type in any way it wants, perhaps 
> stack  allocating it. Removing 'new' removes the implied heap allocation 
> allowing  the compiler to allocate however it likes.
> 

I disagree.

If you want the compiler to be able to optimize by using stack 
allocation instead of heap allocation, then let it do that with the new 
keyword.  I'm assuming the program's behaviour would be the same in 
either case, so it wouldn't matter to me.

If you want stack allocation then how about
scope A a = A();

It keeps the concepts of scope and allocation seperate.  Scope is not 
allocation.  For instance, if the function is inlined then something 
allocated on the stack should live longer than the scope of the 
function.  The only exceptions I can think of are if the compiler 
forbids inlining of such functions (possibly inefficient) or there is a 
scope guarantee, in which case you want scope AND stack alloc.  Or maybe 
I just don't understand inlining (hope not!).

> I don't see the utility in static opCall, I say abolish/remove it.  
> Non-static opCall on the other hand can be quite useful.
> 
> Regan

Please don't abolish/remove it.  At least not until you have convinced 
me that it is totally useless.  I really don't like the idea of dropping 
a language feature just for the sake of having a particular syntax that, 
IMO, is not intuitive.  As I said in the 1.0 thread, A a = A(); looks to 
me like anything but a scoped instanciation; I'd rather have a keyword 
(like scope) to indicate what it is in an explicit way.

 From my previous post about this:
> I like being able to use types as functions.
> Here's one example where I do something similar to what you'd use nested functions for, but better - my forward referencing woes go away.
> 
> class F
> {
>     int result;
>     int tempVar1;
> 
>     static int opCall( int x )
>     {
>         F f = new F(x);
>         int result = f.result;
>         delete f;
>         return result;
>     }
> 
>     this( int x )
>     {
>         internalFunc1();
>         // do stuff
>     }
> 
>     private void internalFunc1()
>     {
>         if ( maybe )
>             internalFunc2();
>         else return;
>     }
> 
>     private void internalFunc2()
>     {
>         if ( maybe )
>             internalFunc1();
>         else return;
>     }
> }
> 
> void main()
> {
>     int x = 42;
>     x = F(x);
> }
> 
> Under the hood, it may also behave differently than nested functions, which could be advantageous.  I'm not sure that it is advantageous, but options are always nice.
> 
> That and you can make nice syntax sugars for alternative memory management methods like freelists, without messing with overriding 'new()'. 

I do like using the scope keyword for this btw.  It seems quite 
consistant with D's meaning of 'scope'.