auto, var, raii,scope, banana

Regan Heath regan at netwin.co.nz
Tue Jul 25 16:43:40 PDT 2006


On Tue, 25 Jul 2006 10:17:13 -0700, kris <foo at bar.com> wrote:
> Don has a good point: changing to "var" would cause conflict with  
> existing variable-names.
>
> Chad et. al. also have a good point about the conflict regarding static  
> opCall() (via the lack of a "new" keyword). I suspect many people find  
> the use of "new" to be indicative of allocation, and breaking this  
> consistency may have a detrimental effect? Further, it was noted that a  
> missing "new" can only be used at the instantiation site -- not at the  
> class decl -- thus, D would be losing an existing feature.
>
> I suspect you could count the current number of raii-class uses on a few  
> hands, whereas the use of "auto" for implied-type is pretty darned  
> popular -- and rightly so, since it's really very, very useful. Changing  
> the raii style to use a different keyword, whilst retaining implied-type  
> "auto" would be an almost imperceptible change?
>
> Thus, it would appear to make sense to retain "auto" for implied-type,  
> and introduce something *else* for automatic cleanup at end-of-scope  
> (and also as a class attribute). how about reusing the "scope" keyword?
>
> void main()
> {
>    auto i = 10;
>    auto foo = new Foo;
>    auto scope bar = new Bar;
>    auto scope wumpus = new Wumpus;
> }
>
> class Foo {}
>
> class Bar {}
>
> scope class Wumpus {}

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



More information about the Digitalmars-d mailing list