LINQ in C#

[Egghead]

Hi here,

Does LINQ only work with "var" in C#?

It only works:
int[] cc = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
var b = from p in cc where (p > 4) select p;

but not this:

int[] cc = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
int[] b = from p in cc where (p > 4) select p;

cheers,
Robert

 

[Oliver Sturm]

Hello Robert,

Does LINQ only work with "var" in C#?

No. Although I personally wouldn't see a reason to not use it most of the
time.

It only works:
int[] cc = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
var b = from p in cc where (p > 4) select p;

but not this:

int[] cc = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
int[] b = from p in cc where (p > 4) select p;

Well, that's true. The expression "from p in cc where (p > 4) select p"
returns IEnumerable<T> (IEnumerable<int> in your case), not an array. You
don't have to use var - you could use this instead:

IEnumerable<int> b = from p in cc where (p > 4) select p;


Oliver Sturm

 

[Egghead]

Hello Robert,

Does LINQ only work with "var" in C#?

No. Although I personally wouldn't see a reason to not use it most of the
time.

It only works:
int[] cc = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
var b = from p in cc where (p > 4) select p;

but not this:

int[] cc = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
int[] b = from p in cc where (p > 4) select p;

Well, that's true. The expression "from p in cc where (p > 4) select p"
returns IEnumerable<T> (IEnumerable<int> in your case), not an array. You
don't have to use var - you could use this instead:

IEnumerable<int> b = from p in cc where (p > 4) select p;


Oliver Sturm

 

[Egghead]

Thanks,

"var" is local variable declaration.

Anyway, with IEnumerable<t>, I find no problems.

cheers,
Rob

Hello Robert,

Does LINQ only work with "var" in C#?

No. Although I personally wouldn't see a reason to not use it most of the
time.

It only works:
int[] cc = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
var b = from p in cc where (p > 4) select p;

but not this:

int[] cc = { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
int[] b = from p in cc where (p > 4) select p;

Well, that's true. The expression "from p in cc where (p > 4) select p"
returns IEnumerable<T> (IEnumerable<int> in your case), not an array. You
don't have to use var - you could use this instead:

IEnumerable<int> b = from p in cc where (p > 4) select p;


Oliver Sturm

 

[Oliver Sturm]

Hello Egghead,

"var" is local variable declaration.

Anyway, with IEnumerable<t>, I find no problems.

"var" is like a placeholder for a type that you don't know when you write
the code. The use of var in this place has exactly the same result as
mentioning the type explicitely.


Oliver Sturm

 

[Nicholas Paldino [.NET/C# MVP]]

I believe that "var" needs a little more clarification here.

When you use "var", you are saying to the compiler "infer the type of
the variable here from the right-hand side". So, when you have something
like:

var i = 0;

It tells the compiler that i is to be inferred from 0, which results in
i being typed as an int.

This is important for anonymous types, when you don't know the type on
the right hand side (we know what it is like, but we dont know the specific
type). For instances where you know the type, I believe that you shouldn't
use var. In the OP's original post, where you are returning
IEnumerable<int>, I believe that that type should be used (as it is known)
and not var.

The argument has been made that you can use var for types with large
names (such as large generic types, e.g. Dictionary<List<IList<List<int>>>,
List<string>>). However, I STRONGLY disagree with this position, as there
is already a mechanism in the language to aid with type aliasing, which is
the using declaration.

Hope this helps.

 

[Oliver Sturm]

Hello Nicholas,

This is important for anonymous types, when you don't know the type on the
right hand side (we know what it is like, but we dont know the specific
type). For instances where you know the type, I believe that you
shouldn't use var. In the OP's original post, where you are returning
IEnumerable<int>, I believe that that type should be used (as it is known)
and not var.

Well, I don't agree. I totally see your point, and I agree, that var
shouldn't be used all the time, and certainly not in the infamous "var i =
0;" case. But I see no harm, and in fact considerable benefit, in a
statement like this:

var myDict = new Dictionary<List<IList<List<int>>>, List<string>>();

Second, in a statement using a LINQ query expression, the type is not
obvious, it's not even there at all in the code. I know it's not entirely
the same thing, but I would also liken the implicit mention of the return
type to relying on an implementation detail. In any case, while I would
expect a good programmer who's familiar with LINQ to know what the return
type of such an expression is, I find the use of "var" with LINQ
expressions entirely acceptable and very useful, even if anonymous types
are not used.

The argument has been made that you can use var for types with large names
(such as large generic types, e.g. Dictionary<List<IList<List<int>>>,
List<string>>). However, I STRONGLY disagree with this position, as there
is already a mechanism in the language to aid with type aliasing, which is
the using declaration.

I already said above that my point of view is apparently different, but I
just want to mention that I don't understand what "the using declaration"
has to do with "types with large names", as you call them.


Oliver Sturm

 

[Barry Kelly]

I personally think type aliasing is confusing, because it's so seldom
used, and it gives multiple names to isomorphic and compatible types.

I'm a fan of 'var' for a different reason, because it eliminates
redundant information (and thus the code is more general), without
removing type safety. I'm familiar with this approach from functional
languages such as Haskell, and it works nicely when things don't get too
complex - as they shouldn't in the case of initialization expressions.

I already said above that my point of view is apparently different, but I
just want to mention that I don't understand what "the using declaration"
has to do with "types with large names", as you call them.

The using declaration he's talking about looks like:

using IntList = List<int>;

.... at the start of a file. It's more useful for resolving conflicts
when you want to import two or more symbols which have the same base
name in different namespaces, yet not have to explicitly qualify it
every time.

-- Barry

 

[Nicholas Paldino [.NET/C# MVP]]

Barry pointed out how the using statement can be used. As for using the
var statement for the return value of LINQ statements, I agree, they should
be used, if you are using a projection (anonymous type) where you have an
IEnumerable<T> where T is anonymous.

 

[Oliver Sturm]

Hello Barry,

The using declaration he's talking about looks like:

using IntList = List<int>;

... at the start of a file. It's more useful for resolving conflicts
when you want to import two or more symbols which have the same base
name in different namespaces, yet not have to explicitly qualify it
every time.

Wow, I'd totally forgotten about that. I agree, I find it confusing as
well... in C everybody used to use so many typedefs, and the main result
was that is became a lot harder to figure out the actual type of a
variable. So, I understand how this relates to using "var" to avoid
mentioning the type twice, but I still think that "var" offers the much
better approach.


Oliver Sturm

 

[Oliver Sturm]

Hello Nicholas,

As for using the var statement for the return value of LINQ statements, I
agree, they should be used, if you are using a projection (anonymous type)
where you have an IEnumerable<T> where T is anonymous.

Well, we'll have to agree to disagree then. I see a lot of useful purpose
in the other use cases of "var" that we have discussed, where I can see
advantages but no significant disadvantages.

Anyway, thanks for your contribution - the OP was trying to find out about
the "var" statement, and these considerations that we posted should
certain be given some thought, regardless of the outcome. In the end I
think these decisions are really of the personal/team preference kind.


Oliver Sturm