auto, var, raii,scope, banana

[xs0]

> I say lets keep 'auto' for auto type inference (for the reasons you and 
> Don mention)

agreed.

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

Why would you want to deal with where the object is allocated? Besides 
speed, is there any reason at all to allocate on the stack?

If you always type the same thing, the compiler is always free to choose 
the best location. If you restrict "new" to allocating on the heap, you 
prevent the compiler from optimizing (by allocating on the stack) 
whenever it determines it's safe to do so (scoped variables are not the 
only such case).

Imho, "scope" is a perfect keyword for scoped variables/classes, for 
reasons already stated (already exists, good meaning, explicit). A 
missing "new" is not a good keyword ;)

By the way, I think it would be wise to require references to 
scope-classes also be tagged with scope, so it'd be harder to miss that 
not-so-insignificant detail about them..

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

But there is utility in static opCall in structs; having them there but 
not in classes doesn't sound to cool/consistent..


xs0