What is the correct use of auto?

Unknown W. Brackets unknown at simplemachines.org
Fri Apr 11 09:47:49 PDT 2008


Understand that "auto" cannot be used as a return type.  Thus, 
"library.getSomething()" has a concrete, deduceable type.

In other words, for:

auto valueType = library.getSomething();

Always has a single type for "auto".  The type is determined during 
compilation, *not* during runtime.

So, suppose this is some struct.  In C, you often use structs to pass 
around state.  I'm just suggesting that when you don't know/care what 
the variable is, you let the compiler deal with it (instead of the 
human, bad you.)

Autosense (I assume you're talking about IDEs) can be determined because 
of the return type of library.getSomething().  It is completely 
deterministic.

The "souffle" variables properties are entirely known at compile time. 
They simply are not being specified by you (most likely because you 
neither know its properties nor care.)  The compiler knows all.

It's important to understand that after compiling, "auto" and "Souffle" 
are exactly equivalent there.  The compiler determines that it is 
"Souffle" and it is as if you had typed that (you just didn't.)

Paper pushing: often you are shuffling around a value between different 
functions.  It could be an int handle, a void pointer, a struct, a 
pointer to something, a class object, a string.  Who cares?  Do you 
care?  No.  As long as the compiler knows what it is, that's all you 
care about.

Function 1 will always return a value that function 2 will take, and you 
never know its properties anyway.  So you're pushing a value between the 
two and you don't care about its actual type or value.  Let the compiler 
worry about that.

-[Unknown]


Hans W. Uhlig wrote:
> Unknown W. Brackets wrote:
>> A great example is when using a library.  Instead of using a "void*" 
>> or something like that, you'd use an auto.
>>
>> Example:
>>
>> auto valueType = library.getSomething();
> 
> I am coming from C and Java (sorry no C++), why wouldn't you declare a 
> typed variable to store the class. Doesn't using auto introduce 
> ambiguity to the compiler and the code itself.
> 
> And this is secondary but how would you use any form of autosense 
> against this since its type can change from execution to execution.
> 
>>
>> auto souffle = library.makeSomethingSouffle(valueType);
>> library.somethingElse(souffle);
>>
> 
> Again what is a souffle and why wouldnt you want it to be
> Souffle mySouffle = library.makeSomethingSouffle(valueType); so that its 
> properties are known at compile time.
> 
>> Another use is when a particular section of your code doesn't care 
>> about the type, and you're just paper-pushing.  This way, even if you 
>> need to change the type later, you don't have to revisit the code 
>> (just recompile it.)
> 
> why bother to paper push if the value is unnecessary. Why not simply 
> discard and move on?
> 
>>
>> It's also handy for this:
>>
>> auto abc = new com.example.somethinglong.modulename.Package();
>>
>> Although mostly you would use an alias for that anyway.
>>
>> And that's not even mentioning templates, where it's very very useful.
>>
>> -[Unknown]
>>
>>
>> Hans W. Uhlig wrote:
>>> I have been reading through the specification and playing with D more 
>>> and more, what is the purpose of auto. I can understand in languages 
>>> with scalar types handling datatypes on assignment but on a strictly 
>>> typed language like C or D when would auto(as a variable declaration) 
>>> provide more useful functionality then it removes from readability.
>>>
>>> When would this be useful rather then simply specifying the type?



More information about the Digitalmars-d mailing list