auto storage class - infer or RAII?

Bill Baxter wbaxter at gmail.com
Sat Nov 11 21:26:21 PST 2006


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

Interesting.  That does kinda make sense when seen in that light.  So it 
does just mean 'an automatic variable' in the traditional K&R sense.

Still don't like it.  I can understand that there is some logic behind 
the madness now, but the logic still doesn't seem like a good 
justification for confusing special cases.   I mean given that meaning 
of auto,  "auto Class c = foo()" should have no more implications than 
than that of "auto int c = foo()".  It should mean stack memory is 
automatic.  If you want to clean up the object too, then you need 
something else, like another 'auto'.  So that would be

    int c = foo(); // automatic stack (normal)
    Class c = foo(); // automatic stack (normal)
    auto int c = foo() // automatic statck (normal)
    auto Class c = foo() // automatic stack (normal)
    auto c = foo() // automatic stack, type omitted so inferred
    auto auto Class c = foo() // automatic stack *and* automatic heap
    auto auto c = foo() // auto stack *and* auto heap *and* type omitted

Throwing in the special case rule 'if the thing is an object then you 
can leave off one auto' just creates confusion.

>> In the future, I'd like the following to work:
>>
>> 5) auto c = Class();
>>
>> which would mean type inference *and* RAII.
> 
> 
> I like this.  It is consistent with the declaration of other types in D 
> ('new' means dynamic, otherwise scoped), and it associates scoped 
> destruction with the data rather than with the reference which is 
> exactly as it should be.  

But it is ambiguous with static opCall.  That doesn't bother you?

This works now, but I don't see how it could with the above:
------
import std.stdio:writefln;

class Class {
     static bool opCall() { return true;  }
     this() { }
}
void main()
{
     auto a = Class();
     auto b = new Class();

     writefln("typeof a: ", typeid(typeof(a)));
     writefln("typeof b: ", typeid(typeof(b)));
}
------

--bb



More information about the Digitalmars-d mailing list