auto storage class - infer or RAII?

[Sean Kelly]

Kristian Kilpi wrote:
> On Sun, 12 Nov 2006 19:02:18 +0200, Sean Kelly <sean at f4.ca> wrote:
> 
>> Kristian Kilpi wrote:
>>> On Sun, 12 Nov 2006 12:24:35 +0200, Walter Bright 
>>> <newshound at digitalmars.com> wrote:
>>>> Sean Kelly wrote:
>>>>> 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".
>>>>>  As Don explained to me, 'auto' is a storage class in D and in C 
>>>>> along with 'const' and 'static', so type inference doesn't occur 
>>>>> because 'auto' is present so much as because a type is omitted.  
>>>>> The presence of 'auto' merely serves to indicate that the statement 
>>>>> is a declaration (since 'auto' is the default storage class and 
>>>>> therefore otherwise optional).  Type inference occurs with the 
>>>>> other storage classes as well.  I think this is an important 
>>>>> distinction because it seems to be a common misconception that 
>>>>> 'auto' means 'infer the type of this expression' and that a 
>>>>> specific label is necessary for this feature.
>>>>
>>>> True. Consider that type inference works in these cases:
>>>>
>>>>     static a = 3;    // a is an int
>>>>     const b = '3';    // b is a char
>>>>
>>>> So auto doesn't actually ever mean "infer the type", it's just 
>>>> needed because one of the other storage class keywords isn't there.
>>>  So according to this logic, auto should always mean RAII?
>>> E.g.
>>>    auto c = new Class;  //RAII
>>
>> Storage class specifiers are really only intended to indicate how the 
>> labeled variable (in this case a class reference/pointer) is stored. 
>> 'const' places the variable in a special read-only area, 'static' 
>> places the variable in static memory, and 'auto' places the variable 
>> on the stack.  For RAII to apply, the behavior of class references 
>> would probably need to change so the referenced value is destroyed 
>> when the reference goes out of scope, and this would effectively 
>> eliminate any means of returning objects from functions since D 
>> objects cannot be passed by value.
> 
> So 'auto' in "auto c = new Class;" means that 'c' (the variable, not the 
> object referenced by it) is stored in the stack? (That's of course the 
> case whenever 'static' is not used.) 'auto' has nothing to do when RAII 
> should be applied to the referenced object (in princible)?

Yes.

     auto MyClass c = new MyClass;

currently overloads the meaning of 'auto' to specify that the object 
referenced by 'c' when 'c' goes out of scope will be deleted.  Here, 
'auto' isn't really a storage class specifier, although it looks like one.

>>> If not, then one could argue that
>>>    static a = 3;
>>>  declares non-static variable, i.e. the static keyword is used for 
>>> type inference only (whenever the type is omited).
>>
>> Not at all.  This declares a type-inferred static variable.  The type 
>> inference occurs because a type is omitted, but the storage class 
>> specifier still applies.  The same goes for 'const'.
> 
> Yes, I was trying to point out that 'auto' works inlogically when 
> compared to other store classes. :)
> 
> 1a) auto c = new Class();              //non-RAII
> 2a) auto Class c = new Class();        //RAII
> 3a) auto c = some_expression();        //non-RAII
> 4a) auto Class c = some_expression();  //RAII

Agreed.

> Now, lets replace 'auto' with 'static':
> 
> 1b) static c = new Class();              //static
> 2b) static Class c = new Class();        //static
> 3b) static c = some_expression();        //static
> 4b) static Class c = some_expression();  //static
> 
> Because the cases 1b and 3b currently create static variables, so should 
> the cases 1a and 3a create RAII objects.
> 
> (But because auto does not actually mean RAII, well, it's still confusing.)

Yes is is, which is why RAII semantics need to be nailed down before 1.0 
in a way that makes sense.


Sean