1

I am reading this article to understand difference between var and IEnumerable. Author wrote four points like following

  1. Use Var type when you want to make a "custom" type on the fly.
  2. Use IEnumerable when you already know the type of query result.
  3. Var is also good for remote collection.
  4. IEnumerable is good for in-memory collection.

point no. 3 & 4 is not clear to me. Please help to understand these point with examples

Darren
  • 68,902
  • 24
  • 138
  • 144
Atish Kumar Dipongkor
  • 10,220
  • 9
  • 49
  • 77

4 Answers4

6

Everything is wrong here, so briefly at least:

  • This is wrong, the resultant type will always be the type returned, whether specified explicitly or not;
  • you would need to know the type anyway, if you intend to use the result! var doesn't change that;
  • this third item is pure poppycock; it makes no sense in and of itself;
  • IEnumerable generally just does represent an in-memory collection (it doesn't have to, mind, as it's only a contract for collections toi adhere to, regardless of their ultimate storage) and the idea is largely juxtaposed to the rest of this question;

A note on usage of var, though, to give a broader set of notions: using var is generally only a good idea when the resultant type is evident based on the current statement - I don't really understand Darren's reasoning or how that would ever be useful, but consider the following:

var results0 = new List<string>();    // assignment type is obvious 
var results1 = something.GetResult(); // read must investigate to know
Grant Thomas
  • 44,454
  • 10
  • 85
  • 129
  • 1
    I believe the third item is silently comparing against `IQueryable`, but yes: it is poppycock; `var` would be identically fine for either `IEnumerable` or `IQueryable`; on the 4th, I've seen (and written) plenty of `IEnumerable` implementations that don't operate against an in-memory collection. Just to be clear, I agree the article makes a mush of everything here - not a good source of wisdom. – Marc Gravell Jun 17 '13 at 08:04
  • @MarcGravell I was just adding a parenthesised caveat for that last one - I knew the danger. :p – Grant Thomas Jun 17 '13 at 08:05
  • Also, http://stackoverflow.com/questions/2876616/returning-ienumerablet-vs-iqueryablet/2876655#2876655 – driis Jun 17 '13 at 08:59
3

var is a contextual keyword that implicitly types a variable. When you use IEnumerable<T> you are explicitly stating the type to be defined, were as var will use type inference.

It doesn't really make a difference which one you use, more of a coding style IMO, I personally use var when returning something from a collection using LINQ rather than IEnumerable<T> or IQueryable<T>.

var value5 = list.Where(i => i == 5).ToList();
IEnumerable<int> value5 = list.Where(i => i == 5).ToList();

Both will generate the same output.

With regards to point 3 and 4. I don't believe that IEnumerable is any more beneficial for in memory collections at all. Behind the scenes the CLR will infer the variables type (When using var) at runtime, most likely to IEnumerable<T>.

Darren
  • 68,902
  • 24
  • 138
  • 144
  • 1
    I didn't ask u for difference var and IEnumerable. make me clear about 3 and 4 if u know. – Atish Kumar Dipongkor Jun 17 '13 at 07:54
  • 1
    @Atish - since 1 and 2 are already misleading at best, what's the point explaining 3 and 4? – David M Jun 17 '13 at 07:56
  • 3
    @AtishDipongkor - I think the article isn't 100% accurate, behind the scenes the CLR will infer the variable (When using `var`) to the appropriate type, so IEnumerable isn't really better for collections than var as the CLR will convert it to the correct type at runtime. – Darren Jun 17 '13 at 07:57
1

var is just an implicitly typed local variable. You just let the compiler determine the type.

var i = 10; // Implicitly typed
int j = 10; // Explicitly typed

It is also super handy when working with anonymous types, eg.

var anon = new { Foo = "Bar" };
Console.WriteLine(anon.Foo); // Puts "Bar" on console.

More information here.

Viktor Elofsson
  • 1,581
  • 2
  • 13
  • 20
1

If one says var MyList = SomeStringCollection.ToList(); MyEnumerator = MyList.GetEnumerator();, then the type ofMyListwill beList, and the type ofMyEnumeratorwill beList.Enumerator, which is a *value type* that implementsIEnumerator, and will thus exhibit *value semantics*. If the type ofMyListhad beenIEnumerable, the return type ofMyList.GetEnumerator()would have beenIEnumerator`, which has reference semantics.

This difference could be important if e.g. one had a method which read five items from an IEnumerator<String>. If one calls such a method multiple times with a variable of type IEnumerator<String>, each call will read the next five items from the enumeration. By contrast, if one calls such a method multiple times with a value type like List<String>.Enumerator, each call will copy the enumeration state to a new heap object which implements IEnumerator<T>, pass that object to the method (which will read five items through it), and then abandon that object and its associated space (leaving the enumeration state associated with the original variable unaffected).

Note that in probably 99% of cases, either value semantics or reference semantics would be equally acceptable in an enumerator; in the majority of those, value semantics would make code run faster, and only very rarely would it make code run meaningfully slower. Further, there are some cases where knowing that an enumerator will behave as a value type could be semantically useful (e.g. if one wanted to be able to repeatedly re-enumerate part of a collection). On the other hand, it's probably a good idea for code which uses implementations of IEnumerator<T> to be aware of what kind of implementation they may be using.

supercat
  • 77,689
  • 9
  • 166
  • 211