auto storage class - infer or RAII?

[Bill Baxter]

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

Derek Parnell wrote:
>> Type inference and RAII are two distinct, unrelated and orthogonal
>> concepts. Using one keyword in subtly different syntax permutations to
>> indicate both concepts is just plain stupid.

Bruno Medeiros wrote:
> I *fully* agree. It comes a few days late, but I still wanted to say it. 
> The irony and mischeviousness of the statement "The auto storage class 
> currently is a *little fuzzy* in meaning" is teeth-grinding(or 
> something). Walter, I hope that by judging the response in this thread 
> you've seen that everyone agrees that these two language concepts should 
> be well separated. There is really no discussion on that. The question 
> to discuss is rather *how* that separations should be (which keywords, 
> etc.).

I fully agree that they should be made more clearly distinct in the code.

But over the past few days I've also come to understand that there is 
some logic to the status quo.  They aren't totally orthogonal concepts 
when considered in the context of a simple value-type automatic variable.

'auto' for type inference is really just 'auto' for declaring an 
automatic variable, and the type inference is due to lack of specific 
type.

'auto' for RAII can be thought of as saying "this thing acts like an 
automatic variable" in that it's cleaned up just a regular value type 
would be.  int foo = expr(); leaves no traces behind after it's out of 
scope (because it's an automatic variable).  The expression myint foo = 
expr(); looks like it might also leave no traces behind, but that 
wouldn't be the case if myint were a Class.  So in that case  auto myint 
foo = expr() is saying "Really I mean it! Treat this like a plain-old 
value-type automatic variable, no matter what it is -- class, struct, or 
typedef."

That said, even though there is a certain kind of logic behind it, it 
would still be better for the people who have to *write* and *maintain* 
the code if the distinction were made a little more obvious.

--bb