Linq Specifiqs - var

Article
09/28/2005

So this is the start of a series of posts that will dive a little deeper into the new C# 3.0 features. My previous posts covered an overall view of what we were doing with the language as well as the Linq initiative, but didn't delve deep into the nitty gritty behind everything. Hopefully through these posts i can make each individual facet of the future work clearer. I'll also bring up open questions we still have and my own personal thoughts on the where we are now and where i hope to be.

It should be noted that what we have shown at the PDC is just a *preview*. Nothing is set in stone, and it's quite likely that things will definitively change before the final future release. It's my hope that by communicating with the developer community we can end up creating a better C# 3.0 for everyone.

So, i'm going start with the "var" feature. The full name is actually "Implicitly Typed Local Variables", but that's quite a mouthful, so we'll just be calling it the "var" feature for now. So what is this feature? Well, as the full name would imply, it's a feature that allows you to declare a local variable without having to explicitly declare its type. For example, say you currently had the following code within some member:

 int i = 5;
string s = "Hello";
double d = 1.0;
int[] numbers = new int[] {1, 2, 3};
Dictionary<int,Order> orders = new Dictionary<int,Order>();

You could now write that as:

 var i = 5;
var s = "Hello";
var d = 1.0;
var numbers = new int[] {1, 2, 3};
var orders = new Dictionary<int,Order>();

The important thing to realize is that "var" does *not* mean "object". In fact, both code samples above will compile to the *exact* same thing.

So how does this work? Well, unlike a regular local variable declaration, a "var" declaration is required to have not just a name, but also an initializer as well. The compiler will then figure out the type of the initializer expression (which is well defined as per the rules of the C# language) and treat the declaration as if you'd used that type as the local variable type. So if you then try to type:

 s.IndexOf('{'); //This will compile.  's' is a string, and string has an IndexOf(char) method on it.
s.FoobyBoob(); //This won't compile.  string doesn't have 'FoobyBoob' method

To make things clear. "var" isn't some "variant" type (although the name is certainly unfortunate), and it doesn't imply some sort of "dynamic" typing system going on. Your code is statically checked exactly as it would be if you had explicitly written down the type.

Now, right now "var" is just for local variables. Why not allow it for something like a method parameter declaration? Well, say you had the following:

 interface IExample {
    void ShowOff(var parameter); //what type would this be?  It has no initializer to determine the type from
}

class OtherExample {
    void Demonstration(var parameter) { //what type would this be?
        parameter.Convert();            //we can't figure out what type it should be based on what we see here.
    }
}

In the first case, there's simply nothing we could do. Without any sort of code in scope that uses "parameter" we couldn't hope to determine what its type was. In the second case, it's possible we could try to figure out the type somehow, but it would probably be enormously complex and confusing (And often we'd still be unable to figure it out). By limiting to local variables that *have* to have an initializer, we ensure a feature that will be usable and available in pretty all places where local variables are allowed..

So... um... neat... but why would i want that?

That's a fantastic question. Let's start by referring to some shortcomings/negatives first. While implicitness can be quite handy for writing code, it can make things quite difficult when trying to just read code. In all the above examples it's fairly easy to determine what the type of each of the variables is. That's because you have either a nice primitive that you can look at, or the call to some constructor which you can then look directly at to figure out the type of variable. But it's not always that simple. What if you were to have:

 var lollerskates = GetSkates(these, parameters, will, affect, overload, resolution);

Now what do you do? As i said before the type of the variable will be statically determined by the compiler using the expression binding rules that are spelled out in detail in the C# specification. But that in itself is an extraordinary problem. There is a huge number of binding rules, and some of them (like generic type inference) are quite complex. Keeping all those rules in your head and correctly trying to apply them on-the-fly in order to just comprehend what your code means sounds like a rather onerous burden to put on you. In effect we'd be asking you to do the compilers job just so you could answer the question "is lollerskates an IEnumerable or an IList??"

On the other hand, var does make other things nicer. For one thing, it avoids some pretty ugly duplication that arises when you start to write heavily genericized code. Instead of needing to write:

 Dictionary<IOptional<IList<string>>,IEnumerable<ICollection<int>>> characterClasses = 
    new Dictionary<IOptional<IList<string>>,IEnumerable<ICollection<int>>>()

you can now write:

 var characterClasses = new Dictionary<IOptional<IList<string>>,IEnumerable<ICollection<int>>>()

There's a heck of a lot of duplication that you can now cut out. It cleans up your code *and* makes it more readable (IMO). Two plusses that are always welcome in my book. Another benefit is if you have code like this:

 object o = ExistingMethod();

...

object ExistingMethod() { ... }

If you then update ExistingMethod like so:

 string ExistingMethod() { ... }

Well, your code still compiles, however if you want to take advantage of the fact that ExistingMethod returns "string" (i.e. to call some method like IndexOf on them) you'll have to update all your declarations that call from "object" to "string". If you had declared it as:

 var o = ExistingMethod();

then you would only have to update one location while still being able to take advantage of that redefinition everywhere.

Ok. Well, those both seem somewhat *meh*'ish. Convenient sure, but worth the potential negatives in code readability? With C# 2.0 as it exists today... probably not. But with some of the Linq work we have coming up, then the picture changes quite a bit. Let's start by looking at a potential way you can write queries in C# 3.0:

    var q = 
      from c in customers
      where c.City == "Seattle"
      select new {
          c.Name,
          Orders = 
              from o in c.Orders
              where o.Cost > 1000
              select new { o.Cost, o.Date }
      };

In this case we're generating a hierarchical anonymous type (which i'll go in depth on in a future article). Say we didn't have "var", but we *did* have some hypothetical syntax for expressing an anonymous type. We'd end up having to write the following:

   IEnumerable<class { string Name; IEnumerable<class { int Cost; DateTime Date }> Orders }> q =
      from c in customers 
      where c.City == "Seattle" 
      select new { 
          c.Name, 
          Orders = 
              from o in c.Orders 
              where o.Cost > 1000 
              select new { o.Cost, o.Date } 
      };

Good golly! That's a lot to type! As with the "Dictionary" example above, you end up with a declaration with a lot of duplication in it. Why should i have to fully declare this hierarchical type when the structure of the type i'm creating is fairly clear from the query initializing it. You could make things easier for yourself by defining your own types ahead of time instead of using anonymous types, but that would make the act of projecting in a query far less simple than what you can do with anonymous types. Of course, if you want to do this, you're completely able to do so while being fully able to work within Linq system. And, because this seems like a feature with it's own plusses/minuses, and because it seems like people will want to move back and forth between implicit/explicit types depending on the code they're writing, it will make a lot of sense for us to provide user tools for this space. Some sort of refactoring like "Reify variables". Or... since people won't know what the heck that means: "make variable implicit/explicit." :-)

So what do you think? Are there things you do/don't like about "var"? Personally, i think the name is somewhat of a problem. C++ is introducing a similar concept, while calling it "auto". I'm partial to that, but leaning more to making "infer" a keyword itself. I think writing down "infer a = "5" reads very well and helps alleviate confusion issues that might arise with "var".

Comments

Anonymous
September 27, 2005
The comment has been removed
Anonymous
September 27, 2005
C++ already has a concept called "auto" which nobody uses, and it specifically refers to a local (stack-allocated) variable. Since "auto int i;" is the same as "int i;", they could say that if you leave out the type name, you could make sure the "auto" is always there and infer the type if need be. The only question is if you can have a "static auto", as "auto" right now is the opposite of "static".

Since C# doesn't have an "auto" just waiting to be used, I do like "var". However, I definitely like "let" even more -- with the added bonus of looking a bit more like functional languages. Unfortunately that won't work when they get around to allowing infered method return types. "private let SomeMethod(int i)" looks pretty stupid. For that case, though, I prefer "auto" because it implies "automatic".
Anonymous
September 27, 2005
The comment has been removed
Anonymous
September 28, 2005
The comment has been removed
Anonymous
September 28, 2005
Damien,

The term 'var' has nothing to do with VB. 'var' is defined in JavaScript/JScript as a universal (and dynamic) type.

Cyrus,

I think 'infer' is a much better term. I'd accept 'auto', but if it doesn't mean the same thing in C++, it might cause some confusion. Whatever the new term, I'd like to see 'var' dumped for this context.
Anonymous
September 28, 2005
I think var is a very unfortunate name because of the Javascript usage... and since a lot of C# people do ASP.NET and therefore do Javascript also, its bound to lead to confusion.

Frankly however, I'm quite surprised to see this feature appear at all, mostly because it makes code less readable in many ways then code with explicitly set variables. From the outset my understanding was that C# as a language designed to be very readable, and force the programmer to use constructs that may not be normally needed just to make code easier to read (like override on virtual methods in inherited classes). This whole concept seems to go against that idium.

This feature basically requires you to make heavy use of intellisense in order to review and understand someone else's code, because types are easily visible. I actually still print out code on paper when I review it (shocking I know), and this "feature" would make that 10 times more difficult.

I just have this feeling that overall, it will make for sloppy code. As things have progressed, people have less and less understanding of what Visual Studio is doing for them under the hood... and I'd hate to see something as basic as type declaration be another one.

Call me old fashioned.
Anonymous
September 28, 2005
Instead of "infer" how about "imp"?

infer seems too long to type all the time. let is just "too BASIC", I think you'll get push back from that.

Plus, "imp" is an abbreviation (err... of sorts) for "Implicitly Typed Local Variables".
Anonymous
September 28, 2005
I don't care much what you call it. Although I agree that "var" is probably not the best name, I think people will get used to it quickly. "auto" would probably be my first choice, especially as that's what C++ is using; it helps make knowledge transferable between languages (where var actively impedes that by meaning two different things in the languages it appears in).

What I do think though is that it's important to make anonymous types "nonymizable", that is, first-class structural/record types. The more I think about this the more I think it needs to happen. Otherwise what do you do if you have code that uses an anonymous type and you do "extract method" refactoring on it? You can end up with situations where there's code you simply can't extract because there's no type you can use to pass the objects across the method call boundary.

I'm not averse to supporting inference of method return types from "return" statements in the body (in fact I think that's a good idea), but that doesn't help with the parameter types.

So IMHO (who am I kidding with the "humble"? ;) ) you guys (the C# team) should be working with the CLR team to get true structural record types into the CLR itself. These types would have to live either outside all assemblies or in some "magic" assembly that can get types added on the fly (lightweight typegen? please? pretty please?) and then the C# anonymous type behavior can be expressed in those terms and work right across method call and assembly boundaries. Syntax for actually referring to those types is trivial once the infrastructure is in place.

Another benefit of doing that is that people who don't like automatic inference aren't shut out of using anonymous types altogether - they can still use Linq and projection and so on, they just have to type more.
Anonymous
September 28, 2005
I agree that the name should be changed from var to something like infer. I would actually prefer to have the same keyword as the C++ compiler. Also 'var' is already used in JavaScript, but much differently, so it seems that the name 'var' is something that should be avoided if possible (IMHO).
Anonymous
September 28, 2005
On Stuart's point, by using anonymous types we're basically creating a type that can't be used outside the current scope (ie can't be passed to another method) right? Won't that result in horribly long and impossible to understand methods that can't be decomposed into helper methods? Seems like a major maintainability issue.
Anonymous
September 28, 2005
+1 for "infer"

next best choice would be "auto".

ps. RonO - I believe Damien's comment on VB-ish referred to using "let" rather than to "var".
Anonymous
September 28, 2005
My vote is to leave it at "var". I like it. Otherwise my second choice would be "infer". var looks fine to me though, not sure what the hype is all about.

Cool post. Please discuss some cool use of lambdas! :-)
Anonymous
September 28, 2005
infer x = 5;

What does that mean? It reads like you are telling the compiler to infer that x is 5, when in reality you are telling the compiler to infer the type of x from the assignment of 5 to it.

It might be kinda cool to be able to say something like this:

infer<T> x = 5;

or

var<T> x = 5;

and then you can use the actual type, T, which is inferred, at other locations. Its a bit awkward because its not the usual generic declaration semantics, and its a lot more awkward to type than simply 'var'.

Even better might be to say something like this:

<T> x = 5;

Still has that awkward-to-type element to it.

Daniel - actually, I dont know VB well enough - I thought 'var' was in VB, but its actually 'Variant' which is the problem.

I dont think we need to be tiptoeing around usage in other languages. 'var' in javascript is used to declare variables. Fine. 'var' in C# is used to do the same, but also to infer the type. If theres any confusion, its going to be momentary.
Anonymous
September 28, 2005
infer as a key word sounds like it would be perfect (and I like it alot) but on the other hand it really doesn't read well as Damien states.

infer x = 5;

X is a 5

imp as Cory says is a nice keyword to but I would spell it out as imply.

imply x = 5

which, of course, reads as "Imply X as 5" which still doesn't really explictly imply type.

Auto is out as it can cause confusion.

typed is another consideration.

typed x = 5

but it makes it sound like x is typed but typed from what?

implytype or infertype will combine everything in one keyword and make it more readable.

implytype x = 5;
infertype x = 5;

These are just suggestions and not necessarily the best. I just thought I would throw it out there for discussion.
Anonymous
September 28, 2005
Stuart/Damien: Making anonymous (structural) types first class citizens is somethign that is being investigated. For the PDC there simply wasn't any time to do anything that exstensive. If you noticed, all the features that we did demonstrate exist entirely within the langauge level and only depend on .Net 2.0 features. This lack of dependence allowed ust o be very nimble and to produce a preview that people could play around with and which we could use to experiment with.

We'll let you know if/when anything changes regarding this. And i'll definitely go deeper on this on a post regarding Anonymous types.
Anonymous
September 28, 2005
Cyrus, thanks for the info :)

I had actually noticed that most of the C#3 features were purely language level - I hadn't quite made the leap to notice that they were all that way and ran entirely on the unmodified 2.0 platform though.

I'd certainly noticed that 1.x->2.x was a huge CLR change to support generics, the so-far-announced 3.x features at the CLR level were underwhelming. That's not entirely a bad thing - it's a testament to the power and maturity of the platform. But there are still areas that the CLR could use improvement in.

It raises an interesting question: I'd assumed that just like 2.0, C# 3.0 would be released in parallel with the .NET framework 3.0 and a new major revision of the CLR. But I realize now that I don't think I've ever seen that formalized anywhere. Do you know if that's actually been announced yet, one way or the other?

It's certainly impressive to see how far it's possible to push the language with no CLR help, but just like with Nullable, I think there are aspects of this work that would suffer if they ended up enshrined in their current form, because it would prevent doing them "right" in the future. Anonymous types versus first-class structural types is the biggie here.
Anonymous
September 28, 2005
All right, so both the problem and the reward are code readability/repetitiion.

Why not add a feature in Intellisense that can convert:

var i = 5;
var s = "Hello";
var d = 1.0;
var numbers = new int[] {1, 2, 3};
var orders = new Dictionary<int,Order>();

to:

int i = 5;
string s = "Hello";
double d = 1.0;
int[] numbers = new int[] {1, 2, 3};
Dictionary<int,Order> orders = new Dictionary<int,Order>();

------------------------------

That would solve everything for the coders, just by clicking on a button to convert the code. Tell me why this resolution would cause potential problems. I'd like to hear from you.
Anonymous
September 28, 2005
The comment has been removed
Anonymous
September 28, 2005
Grrr... not getting notifications about all these posts. Very frustrating.
Anonymous
September 28, 2005
The comment has been removed
Anonymous
September 28, 2005
The comment has been removed
Anonymous
September 28, 2005
Uh oh, sorry for getting too excited before finishing reading the whole post. Besides, I'm at work, so no time to read carefully. =)

Yeah, having "var" would be nice after all.
Anonymous
September 28, 2005
Loc: I'm forwarding your suggestion to Karen (who'd in charge of how intellisense will work in Orcas). We're going to be thinking a lot about new ways we can show you information.

If you have other suggestions that you'd like to see, then go to http://msdn.microsoft.com/ProductFeedback and submit it there. THat way it will get reviewed by the team and can get voted on by the community. It's too late for it to be ocnsidered for Whidbey, but they will all be considered for Orcas.
Anonymous
September 28, 2005
The comment has been removed
Anonymous
September 28, 2005
Loc: Yup. You have to sign in. That was to prevent the spam assault we were getting when sign in wasn't required.
Anonymous
September 28, 2005
The comment has been removed
Anonymous
September 28, 2005
I agree that 'infer' should be the new keyword.
Anonymous
September 28, 2005
Personally, I think "infer" is a verb (although you can say it's short for the noun), so it shouldn't be a name.

How about just anonymous ("anon" keyword)? Or better yet, "loc" keyword? Just kidding.

I'm ok with var.
Anonymous
September 28, 2005
Loc: "anonymous" would be a pretty poor name :)

anonymous means: Nameless

However, these variables are definitely not nameless. They have names, just not types :)

So i think i'll definitely be 'axing' the "anonymous" keyword right now :)
Anonymous
September 28, 2005
How about... dim? HAR! Sorry.

Seriously, my first preference would be for "auto" since it's the same as in C++ and implies that the type is determined AUTOmatically.

My second choice would be "let" since that's the keyword used by ML/OcaML/F# which invented the concept of implied typing AFAIK.

"infer" reads a bit strangely since C# is inferring the type, not the variable or its value. "var" would actually be an okay choice if it wasn't already used by JavaScript and reminiscent of VB/COM variant types. But since it is... I agree that it's not a good choice.
Anonymous
September 28, 2005
The comment has been removed
Anonymous
September 29, 2005
I meant "anon" as "anonymous type" and not "anonymous variable".

anon orders = new Dictionary<int,Order>();

The variable name is "orders", and the type name is anonymous - or no type. According to dictionary.com:

----------------------------------------
1. Having an unknown or unacknowledged name: an anonymous author.
2. Having an unknown or withheld authorship or agency: an anonymous letter; an anonymous phone call.
3. Having no distinctive character or recognition factor: “a very great, almost anonymous center of people who just want peace” (Alan Paton).
----------------------------------------

How about "anytype" keyword? Or just "any"?
Anonymous
September 29, 2005
Why not simply do without 'var' or 'let' or 'infer', and make type declarations optional.

I mean, a non-declaration, like 'var' really doesnt tell us much at all.
Anonymous
September 29, 2005
Damien, I've thought about that, but then you don't know where it's declared and its scope (like is it a global or local var?). It's confusing, at least to me.
Anonymous
September 29, 2005
loc: theres plenty of precedence for optional type declarations, or at least the absence of them.

In Pyhton, Javascript, Perl, Ruby, Haskell - you dont need to declare your types at all. people use these languages in production environments and dont get confused.
Anonymous
September 29, 2005
Python, Perl/Ruby, and Javascript have dynamic typing, don't they? If those languages were so great, C#/C++/Java would have been much less popular I think. :)
Anonymous
September 29, 2005
Damien: "Why not simply do without 'var' or 'let' or 'infer', and make type declarations optional.

I mean, a non-declaration, like 'var' really doesnt tell us much at all. "

Sure it does. It tells you that you're declaring a variable, as opposed to just using it.
Anonymous
September 29, 2005
The comment has been removed
Anonymous
September 30, 2005
I wonder how the C# team will report errors on an anonymous type. Are we going to get the same huge errors you get when compiling C++ template code?
Anonymous
September 30, 2005
JC: "I wonder how the C# team will report errors on an anonymous type. Are we going to get the same huge errors you get when compiling C++ template code? "

Why don't you try out the alpha and see? If you don't like the errors, let us know so that we can work on it and make it better.
Anonymous
September 30, 2005
Damien: "Since other languages manage just fine without such a declaration, why does c# need it? "

Well, to be nitpicky in return:

a) a lot of the feedback we get from users is that they do not like languages that eschew declarations.

b) There are many different mindsets about this, however our current user base seems to prefer the more staticy declaration-oriented style of programming.

c) technically c# doesn't need anything. It's turing complete and you could always implement every single feature in a roundabout manner. But that would be silly :) Language design is about striking a proper balance between many things and so far we like the balance that "var" gives us.
Anonymous
October 02, 2005
I see where you are going with the reason for 'var' being due to the new Linq features of C# 3.0. I see that it would make things much easier there. I do, however, think that its use outside of this construct will make things much more ambiguous.

Your 'lollerskates' example, in particular, scares me quite a bit. In these cases I would be vehemently against letting my programmers use this feature.

In particular, I worry about those cases where a programmer is being returned a different type than he/she originally anticipated and is using common method names that will still compile. Example (not that you would do this, but consider anyway):

public StringBuilder GetParagraph(){}

var paragraph = GetParagraph();
textbox1.Text = paragraph.ToString();

Now consider the definition of GetParagraph changes:

public MyCustomTypeWithToStringNotOverriden GetParagraph(){}

You'll see here you will get object.ToString() instead of StringBuilder.ToString(). No compilation warnings. This, to me, it the advantage of a strongly typed language. I realize that 'var' does not REALLY change the strong-typedness of C#, but it removes one of those compiler errors that would tell a programmer to look something over and make sure it is still correct.

That's just my 2 cents. Great article! It's great to see what you guys are working on as you go through the design process.
Anonymous
October 03, 2005
Cyrus,

Always good to see you...

Using "auto" or "infer" wouldn't be so bad. There is a suggestion on the Product Feedback site to use "let", but I disagree with that, since the implication is something other than what is actually going on.

I think var is ok, as are the other recommendations you have. However, I think that var is better only because it is shorter, and you will run less of a risk of conflicts with current code (because you are introducing a new keyword, you have this problem).

BTW, you state:

s.FoobyBoob(); //This won't compile. string doesn't have 'FoobyBoob' method

As I am sure you know, with extension methods, it could. =)
Anonymous
October 03, 2005
Instead of "var" or "infer" what about "local"?

e.g.

local x = 5;

It's reasonably short (but not as short as var admittedly), and has the advantage of corresponding to the official name of "Implicitly Typed Local Variables".
Anonymous
October 03, 2005
My first thought on seeing the "var" keyword was that I would actually rather have the compiler able to infer the other side of an assignment. To use your own example:

Dictionary<IOptional<IList<string>>,IEnumerable<ICollection<int>>> characterClasses = new();

Visual Basic has been able to do this for years with their "Dim x As New X()" syntax, and it has the advantage of only removing truly redundant text. Obviously, you still need the "var" keyword for anonymous classes and places where a method returns some truly onerous and hard-to-understand type (if I had a function that returned that particular kind of dictionary in real life, I'd probably actually use "var" for the variable), but I think it removes an awful lot of duplication with basically no cost in terms of readability because the type is always statically declared somewhere in the statement.

Partial inference also might be interesting. What if you could type the above type as:

Dictionary<var, var> characterClasses = ...;

No "real" advantages to this from a syntax perspective, but I think it enhances readability significantly. You still save yourself a lot of typing, but at least you can glance at it and quickly know as much as you need to know about the type of the variable.

All in all, though, as long as the C# 3.0 language service allows me to hover over a var-typed variable and see the actual infered type in a tooltip, I think I'll be satisfied with the readability.
Anonymous
October 04, 2005
ryan, if you search for "meh" and read from there, you'll see that "var" was meant for the linq stuff that's coming in C# 3.0. Basically, if you can't express anonymous type, then declaring this following variable is pretty cumbersome:

var q =
from c in customers
where c.City == "Seattle"
select new {
c.Name,
Orders =
from o in c.Orders
where o.Cost > 1000
select new { o.Cost, o.Date }
};
Anonymous
October 04, 2005
Oh, I'm aware of that -- hence the phrase "Obviously, you still need the 'var' keyword for anonymous classes" in my previous post. I wasn't suggesting replacing the current 'var' functionality, just some extra functionality that I think would be interesting on top of it and would improve overall code readability.
Anonymous
October 06, 2005
The comment has been removed
Anonymous
October 07, 2005
Brian, what if we don't need that functionality? what if we want to throw an error? Anderson (search for andersonimes to read his response) gave an example where throwing an error/warning is desirable when you change the return type of "someMethod".

What you might like to see is classic Intellisense though. :)
Anonymous
October 07, 2005
Well, yes, it's possible that we don't need that functionality, but I think it's kind of nice. I also realize that tooltips display information about methods et cetera, I just want to make sure that it does this to the var keyword itself. Doesn't really help those printing, but it sounds like there's going to be functionality to Reify so that takes care of that. I guess I'm just not convinced that var would cause that much confusion if those two things are in place.

Actually, I did overlook Anderson's post and yes, that could cause some problems. Maybe you're right and it should just automatically change var to the appropriate type.
Anonymous
October 13, 2005
The comment has been removed
Anonymous
October 16, 2005
As an alternative for the "var" keyword, I think "set" is also a fine choice.

Cheers,
Behi
Anonymous
October 16, 2005
What else is going on, Cyrus? Update...

4th quarter is keeping everyone busy. I still haven't looked for PDC articles/webcasts to enjoy...
Anonymous
October 24, 2005
The comment has been removed
Anonymous
October 25, 2005
Heres the main reason I wouldnt like to skip the "var" keyword altogether:

int ill = 5;
ili += 5;
Debug.Assert(ill == 10); // Fails

Did you spot the bug on a single read-through? And even if you did, would you be able to spot the bug at all when you write it yourself (and expect to have not written a bug), especially if you have 20 lines of code in that function?

With "var" you would get a compiler error.

Id prefer "var" or "infer", var is short and to the point. I dont like "set", just try talking about it, "the select function returns a set" (a set variable, or an ISet set?).
Anonymous
November 28, 2005
The keyword should clearly be "???". E.g:

void DoSomething()
{
??? x = GetSomething();
}

So, the nullable version of same would be:

???? x = GetSomething(); //nullable
Anonymous
January 20, 2006
Cyrus - what does it mean that this is the start of a series of posts on C# 3.0 features? You don't seem to have ever covered it again.

Pros and cons of the names:

var - Pro: simple, short, to the point, appears to be the choice already anyway; Con: will be confused with VB variant and JavaScript var.

let - Pro: makes the ocaml hacker in me smile, simple, short, to the point; Con: would be confused with BASIC let statement.

infer - Pro: clarifies that it's type inferencing, not typelessness or variant types (I really liked this idea for a second); Con: as someone pointed out, it's a verb, so it implies that you are telling the compiler to do type inferencing, and thus that the compiler only does type inferencing when you explicitly tell it to, but I believe you are, or are planning to, do it in other cases.

imply, anon, auto, loc - Pro: I can't think of any; Con: yuck, blech, Ack! Pffft!

??? - Pro: too funny; Con: too funny.

x = w? x ?? y : ???? z = from ...
Anonymous
February 22, 2006
The comment has been removed
Anonymous
November 25, 2007
PingBack from http://feeds.maxblog.eu/item_1176372.html
Anonymous
June 01, 2009
PingBack from http://uniformstores.info/story.php?id=1302

Partager via

Linq Specifiqs - var

Comments

Ressources supplémentaires