auto, var, raii,scope, banana

[Don Clugston]

Nils Hensel wrote:
> Don Clugston schrieb:
>> Nils Hensel wrote:
>>> I'm sorry but I don't believe there are many programmers out there 
>>> actually using something as undescriptive as "var" as a regular 
>>> identifier. 
>>
>> Maybe my first impression of the google search yourself -- the data is 
>> there.
> I guess there are regular "var" users then but when I said "programmers"
> I was thinking of professionals used to the idiosyncrasies of medium to
> large software projects, where you're often faced with working on and
> maintaining someone elses code. I guess if the best description of a
> variable's intended meaning this somebody could come up with was "var"
> I'd be pretty pissed pretty soon.

They're normally in trivial one-line functions.

>>> I don't intend to insult Don in any way but it's a horrible practice 
>>> IMNSHO that should not be preserved.
>>
>> I don't understand. I can't see the difference between 'var' and 'x'.
>> Do you also dislike use of 'i' as a counter variable in a for loop?
>> (And if not, what is the difference?)
> 'x' and 'i' are often used in mathematical formulas and contexts so they
> already bear a meaning even if they look indescriptive. OTOH if someone
> uses 'i' as a string or a boolean variable I WOULD consider it a bad 
> practice as well.

>> 'var' is inappropriate in a statically typed language. Remember that 
>> 'static's are variables too. Note that 'auto' was one of the original 
>> C keywords, and was chosen without any constraint (no legacy code 
>> whatsoever, they could have chosen any name, including 'var'). Every 
>> variable was classed into either:
>>
>> static
>> auto
>> register
> To be frank I don't get your point here. "static", "auto" and "register" 
> are storage classes in these contexts (as they are originally in D). C 
> has no concept of type inference. "auto" just means that the memory 
> management for these variables is dealt with automatically because these 
> variables exist on the stack.

> D just uses the fact that "auto" signifies the declaration of a variable 
>  which allows the compiler to identify the type automatically  through 
> the initializing value. The same holds true for "static" and "const". So 
> actually D doesn't have an explicit type inference keyword yet.

No, the idea is *not* to have a type inference keyword, but instead only 
specify the storage class:

static a = 7;
const b = 7;
auto  c = 7;

Now 'a' is a variable, just as much 'c' is.

Are you proposing that you'd have to type:

static var x =  func(7);

? Surely not. 'const var' would be an abomination!

The problem is, there's no storage class for local variables. In C/C++, 
there is, and it's called 'auto', but it's extremely rarely used in 
normal code. 'local' is perhaps the most natural name.


I just don't like the idea that 'var' would mean "local non-static 
variable". "Variable" is a much broader category than "local variable".

I hope that one day D also gets explicit thread-local variables. They 
would need a seperate storage class.

>>> Also I don't think that it's a good habit to be looking at how C++ 
>>> does something unless one is looking for a bad example. My main 
>>> reason for interest in D is because personally I'm fed up with C++ 
>>> and consider it an abomination and a major PITA.
>>
>> Agreed, but the 'auto' thing ultimately comes from C, not C++.
> Yes, but not in the context of type inference. So the C "auto" is 
> totally different from it's current D counterpart.

No, it's not. It's a storage class in C++, *not* a type inference 
keyword. It's just that it's a storage class that in modern times is 
only used in the context of type inference.


I think 'var' makes much more sense for dynamically typed languages. 
Still, I just learned that C# 3.0 is going to use it.
What is the C# 3.0 type inference syntax? How does it deal with type 
inference of constants?