Better word for inferring variables other than var - C#

Question

This might get closed, but I'll try anyway.

I was showing a VB6 programmer some of my C# code the other day and he noticed the var keyword and was like "Oh a variant type, that's not really strong typing when you do that." and I had to go on the typical "var != VARIANT" speech to explain to him that it is not a variant it just compiler inferred.

I was thinking about other words they (C# team) could have used so this kind of thing didn't happen. I personally like infer, something like:

 infer person = new Person("Bob");

I know this is not really that big of deal, but just curious to see what other people would use to do the same thing.

I have made this a community wiki because it doesn't really have an answer.

Answer 1

I think this is a great idea. I myself have had to explain the var keyword from time to time and how it is really just a placeholder for a type and that it still insures strong typing.

infer works for me! :)

Answer 2

If the keyword was named variable instead of var, then we may not see this kind of confusion. This may have been the intent, but someone clearly thought that typing variable was too verbose, leading to the ambiguity we have today.

Answer 3

But "infer" is 2 more characters than "var"... Maybe "var" wasn't the best thing to put in front of a VB6 programmer at first...

Answer 4

How about foo ?

Answer 5

C++0x uses the "auto" keyword for type inference:

http://en.wikipedia.org/wiki/C%2B%2B0x#Type_inference

That's not a bad trade-off for those guys since "auto" was (AFAIK) already a keyword. I can imagine it in C#:

auto i = 3;

I do like "infer" though (but then I don't have any problem with "var" either).

Answer 6

On the other hand, Pascal/Delphi and ActionScript programmers immediately grasp the true meaning of var. So why single out VB6? It is unfortunate that it had Variant in it, and so VB6 guys quickly substitute var for that, but no matter which way you go, someone somewhere will be confused.

Given that VB6 is legacy for quite a while now anyway, that var is perfectly clear to someone without the burden of past experience (I mean, how many people new to programming would think of var meaning something different from "variable"?), and that var has been specifically used to mean "variable" by several other popular languages, it doesn't seem like a bad choice.

The obvious problem I see with infer keyword as given is that it's not obvious that it infers the type of variable. Just looking at it, it might as well be inferring its value or something (especially if RHS is not a new-statement).

Answer 7

How about reviving ye olde BASIC keyword LET?

let answer = 42;

Answer 8

I like var, and think the meaning in the context of a strongly-typed language is clear. dynamic, on the other hand, is the "oddball" in C# code so the longer semantic naming is appropriate.

Answer 9

thisappearsweaklytypedbutisactuallystronglytyped i = 3;

It's the only way to avoid confusion! Don't worry, autocomplete means it won't really take that much longer to type...

Answer 10

C# is supposed to be all symbolly, like C++, not all keywordy, like VB. How about "?"

? X = 5;
? Y = X.ToString();
? Z = Y + Y;

What type is Z? Who knows?

Answer 11

I think C# would be better with no "static type inference" keyword at all. So it would work like this:

myDict = new Dictionary<string, MyClass>();

I was wondering why C# designers felt a keyword like "var" was needed for static type inference. Was it necessary to comply with C#'s fundamental grammar rules? Was it because they had already thought about "dynamic" and wanted to make the distinction more clear between static and dynamic type inference?

In any case, after some prolonged exposure to Python, "var" (or any alternative keyword or qualifier) feels completely superfluous. Take the following code:

foreach ( item in myList ) {
    // Do stuff
}

What additional information would adding "var" in front of "item" give to the reader?

Answer 12

Not completely on topic, but VB.NET does this almost too cleanly. I bet it's even more confusing for ex VB6 users.

Dim p = New Person()

Is that using late binding or type inference? Better check your project properties.