auto storage class - infer or RAII?

[Daniel Keep]

Walter Bright wrote:
> The auto storage class currently is a little fuzzy in meaning, it can
> mean "infer the type" and/or "destruct at end of scope". The latter only
> has meaning for class objects, so let's look at the syntax. There are 4
> cases:
> 
> class Class { }
> 
> 1) auto c = new Class();
> 2) auto Class c = new Class();
> 3) auto c = some_expression();
> 4) auto Class c = some_expression();
> 
> The ambiguity can be resolved by saying that if auto is used for type
> inference, i.e. cases (1) and (3), then it does not mean RAII. If it is
> not used for type inference, i.e. cases (2) and (4), then it does mean
> RAII.

What I would prefer is if you introduced a new keyword that meant
"declare".  Just that.  auto is currently used for type inference not
because it MEANS "infer the type" but because it's the default storage
class.  Currently, declarations look like this:

  [storage class] [type] [name]

We can omit the type if we supply the storage class, or we can omit the
storage class if we supply the type.  But there's no way to omit both.
So I propose that you add a new keyword so that declarations become the
following:

  [declaration] [storage class] [type] [name]

This way, we can omit [declaration] if we supply either [storage class]
or [type], omit [storage class] if we supply [declaration] or [type],
and can omit [type] if we supply [declaration] or [storage type].

Let's say the keyword is chosen to be "def" (being short for "define").
 This gives us:

> Class c = new Class();	// normal decl.
> def Class c = new Class();	// as above
>
> auto Class c = new Class();	// RAII decl.
> def auto Class c = new Class(); // as above
>
> auto c = new Class();		// RAII with type inference
> def auto c = new Class();	// as above
>
> def c = new Class();		// type inference with no RAII

Another keyword choice could be "let" (which allows you to "read" the
declaration out loud).  "var" makes no sense since you could conceivably
put it before a "const", and that doesn't make any sense:

> var const x = foo;  // Is it a constant or a variable??

This will let you keep the "auto" keyword, whilst still giving us what
we want -- everybody wins!

> In the future, I'd like the following to work:
> 
> 5) auto c = Class();
> 
> which would mean type inference *and* RAII.

Please, no.  It breaks static opCall (which I *do* use), and makes no
sense.  Everywhere else in D requires the "new" keyword; why not for
this one particular case?

On a related note, I don't suppose I could ask you to take a second look
at my old proposal on allowing auto objects to be returned from
functions, could I? :P  It is one of the very, very few things I'd still
like to see in D 1.0.

<http://www.digitalmars.com/d/archives/digitalmars/D/38329.html>

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even
make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/