implicit types in C# 3.0, what is the usefulness of them?

[Chris Dunaway]

The C# 3.0 spec (http://msdn.microsoft.com/vcsharp/future/) contains a
feature called "Implicitly typed local variables".

The type of the variable is determined at compile time based on the
expression to the right of the = sign:

var s = "Hello"; //s is strongly typed to be a string
var i = 25; //i is strongly typed to be an integer

But what I don't understand what advantage it is?

string s = "Hello"; //This is just as easy to type and is easier to
read

What's the story?

 

[gmiley]

I guess it would be for the sake of more polymorphic code...? That's my
best guess as if I ever saw someone use that in any normal code I would
smack them... this is of course assuming that I do not hear of any
other valid reason for it.

 

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

Chris,

The reason this was introduced was to support LINQ, for permutations on
queries. Basically, when performing a query on an enumerable type, you can
choose what to return. For example, say you have a class with three
properties, FirstName, LastName, and Id. When you perform a query, you can
choose to return a type with just the Id and the LastName. The thing is,
you don't know what that type will be (well, you do, but creating a
compatable type is a pain if you have to do it all the time).

This is where var comes in. It is used along with these anonymous types
to allow implicit typing (after all, what type would you use for the
anonymous type you just created).

Hope this helps.

 

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

gmiley,

See my response, tell me if you think it is valid

I agree, if you know the type beforehand, then yes, you should not use
it, but if you don't know the type (see my response for why you wouldn't
know), you will need this.

 

[gmiley]

Yep, i see your point on that, didn't think of it that way. Thanks.

 

[William Stacey [MVP]]

I had a similar question I was asking myself. I understand the need for
anonymous types, but why the "var" key word: See below:
public void Linq1() {
int[] numbers = { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 };

var lowNums =
from n in numbers
where n < 5
select n;

Console.WriteLine("Numbers < 5:");
foreach (var x in lowNums) {
Console.WriteLine(x);
}
}

lowNums is Anonymous type, so why not just a type of AType (assuming AType
exists in the FX) instead such as:

AType lowNums =
from n in numbers
where n < 5
select n;
foreach(Atype at in lowNums)
{
Console.WriteLine(at);
}

Is "var" then just sugar? If so, not so sure I like it at first blush.
Maybe there is some other reason.

--
William Stacey [MVP]

Chris,

The reason this was introduced was to support LINQ, for permutations on
queries. Basically, when performing a query on an enumerable type, you
can choose what to return. For example, say you have a class with three
properties, FirstName, LastName, and Id. When you perform a query, you
can choose to return a type with just the Id and the LastName. The thing
is, you don't know what that type will be (well, you do, but creating a
compatable type is a pain if you have to do it all the time).

This is where var comes in. It is used along with these anonymous
types to allow implicit typing (after all, what type would you use for the
anonymous type you just created).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

The C# 3.0 spec (http://msdn.microsoft.com/vcsharp/future/) contains a
feature called "Implicitly typed local variables".

The type of the variable is determined at compile time based on the
expression to the right of the = sign:

var s = "Hello"; //s is strongly typed to be a string
var i = 25; //i is strongly typed to be an integer

But what I don't understand what advantage it is?

string s = "Hello"; //This is just as easy to type and is easier to
read

What's the story?

 

[Mark White]

Nicholas

Sorry for being dense here, but wouldn't the type returned with just Id and
LastName be that of the original type?

Is this MS basically regressing back to VBScript with the variant type? At
least in Chris's example it looks that way.

Mark

Chris,

The reason this was introduced was to support LINQ, for permutations on
queries. Basically, when performing a query on an enumerable type, you can
choose what to return. For example, say you have a class with three
properties, FirstName, LastName, and Id. When you perform a query, you can
choose to return a type with just the Id and the LastName. The thing is,
you don't know what that type will be (well, you do, but creating a
compatable type is a pain if you have to do it all the time).

This is where var comes in. It is used along with these anonymous types
to allow implicit typing (after all, what type would you use for the
anonymous type you just created).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

The C# 3.0 spec (http://msdn.microsoft.com/vcsharp/future/) contains a
feature called "Implicitly typed local variables".

The type of the variable is determined at compile time based on the
expression to the right of the = sign:

var s = "Hello"; //s is strongly typed to be a string
var i = 25; //i is strongly typed to be an integer

But what I don't understand what advantage it is?

string s = "Hello"; //This is just as easy to type and is easier to
read

What's the story?

 

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

William,

The need for var comes when you do this:

Customer[] customers = GetCustomers();
var custs = customers.Where(c => c.City == "Seattle").Select(c => c.Name);

Or, as C# 3.0 would support it:

Customer[] customers = GetCustomers();
var custs = from c in customers where c.City == "Seattle" select c.Name

Since the new type would only have Name as a property, it can't be of
type Customer. It is anonymous, and you need a way of saying "hey, I have
this strongly-typed thingie over here, but I don't know what it's named. I
know what it does, but you take care of the name, and tell me if I do
something with it that's funky".


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I had a similar question I was asking myself. I understand the need for
anonymous types, but why the "var" key word: See below:
public void Linq1() {
int[] numbers = { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 };

var lowNums =
from n in numbers
where n < 5
select n;

Console.WriteLine("Numbers < 5:");
foreach (var x in lowNums) {
Console.WriteLine(x);
}
}

lowNums is Anonymous type, so why not just a type of AType (assuming AType
exists in the FX) instead such as:

AType lowNums =
from n in numbers
where n < 5
select n;
foreach(Atype at in lowNums)
{
Console.WriteLine(at);
}

Is "var" then just sugar? If so, not so sure I like it at first blush.
Maybe there is some other reason.

--
William Stacey [MVP]

Chris,

The reason this was introduced was to support LINQ, for permutations
on queries. Basically, when performing a query on an enumerable type,
you can choose what to return. For example, say you have a class with
three properties, FirstName, LastName, and Id. When you perform a query,
you can choose to return a type with just the Id and the LastName. The
thing is, you don't know what that type will be (well, you do, but
creating a compatable type is a pain if you have to do it all the time).

This is where var comes in. It is used along with these anonymous
types to allow implicit typing (after all, what type would you use for
the anonymous type you just created).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

The C# 3.0 spec (http://msdn.microsoft.com/vcsharp/future/) contains a
feature called "Implicitly typed local variables".

The type of the variable is determined at compile time based on the
expression to the right of the = sign:

var s = "Hello"; //s is strongly typed to be a string
var i = 25; //i is strongly typed to be an integer

But what I don't understand what advantage it is?

string s = "Hello"; //This is just as easy to type and is easier to
read

What's the story?

 

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

Mark,

No, they are not. The compiler is actually creating a new type with
just the Id and Name property. VB Script would interpret the calls to a
property and get them off the original type. This is a new type that is
being returned (and local to the method).

In Chris's example, yes, those types are string, int, etc, etc.
However, that's really not what the var keyword is meant to support. It's
meant to support the LINQ in C# (which can return just subsets of properties
on a type).

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Nicholas

Sorry for being dense here, but wouldn't the type returned with just Id
and
LastName be that of the original type?

Is this MS basically regressing back to VBScript with the variant type?
At
least in Chris's example it looks that way.

Mark

in
message news:[email protected]...

Chris,

The reason this was introduced was to support LINQ, for permutations on
queries. Basically, when performing a query on an enumerable type, you can
choose what to return. For example, say you have a class with three
properties, FirstName, LastName, and Id. When you perform a query, you can
choose to return a type with just the Id and the LastName. The thing is,
you don't know what that type will be (well, you do, but creating a
compatable type is a pain if you have to do it all the time).

This is where var comes in. It is used along with these anonymous types
to allow implicit typing (after all, what type would you use for the
anonymous type you just created).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

The C# 3.0 spec (http://msdn.microsoft.com/vcsharp/future/) contains a
feature called "Implicitly typed local variables".

The type of the variable is determined at compile time based on the
expression to the right of the = sign:

var s = "Hello"; //s is strongly typed to be a string
var i = 25; //i is strongly typed to be an integer

But what I don't understand what advantage it is?

string s = "Hello"; //This is just as easy to type and is easier to
read

What's the story?

 

[gmiley]

I don't think that this is meant to be used as an everyday type, I
still stand by my smacking of people using 'var' when unnecessary.

I can see its application though, as I said, in polymorphism.

public abstract class AClass
{
var UnknownReturnMethod();
public int SomeIntegerMethod()
{
// code
return 0; //or an int variable
}
}

public class myClass : AClass
{
var UnknownReturnMethod()
{
return something;
}
public string KnownReturnMethod()
{
return (string)UnknownReturnMethod();
}

}

 

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

gmiley,

That won't compile. The var keyword is only valid in property and
method implementations (that's why they are called implicitly typed local
variables, the focus being on local).

 

[William Stacey [MVP]]

Customer[] customers = GetCustomers();

var custs = customers.Where(c => c.City == "Seattle").Select(c => c.Name);

Or, as C# 3.0 would support it:

Customer[] customers = GetCustomers();
var custs = from c in customers where c.City == "Seattle" select c.Name

Since the new type would only have Name as a property, it can't be of
type Customer. It is anonymous, and you need a way of saying "hey, I have
this strongly-typed thingie over here, but I don't know what it's named.
I know what it does, but you take care of the name, and tell me if I do
something with it that's funky".

Thanks Nicholas. But why not write it like below:

Customer[] customers = GetCustomers();
AType custs = from c in customes where c.City == "Seattle" select c.Name

AType is not some type I created, but the System's Anonomous Type class.
"custs" is still an anonymous type, but it is more direct what we are taking
about and potentially less confusing. There must be a reason they wanted
that "var" keyword.

 

[Mark White]

Gotcha. That cleared it up for me, thank you.

Mark,

No, they are not. The compiler is actually creating a new type with
just the Id and Name property. VB Script would interpret the calls to a
property and get them off the original type. This is a new type that is
being returned (and local to the method).

In Chris's example, yes, those types are string, int, etc, etc.
However, that's really not what the var keyword is meant to support. It's
meant to support the LINQ in C# (which can return just subsets of properties
on a type).

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Nicholas

Sorry for being dense here, but wouldn't the type returned with just Id
and
LastName be that of the original type?

Is this MS basically regressing back to VBScript with the variant type?
At
least in Chris's example it looks that way.

Mark

in
message news:[email protected]...

Chris,

The reason this was introduced was to support LINQ, for

permutations
on

queries. Basically, when performing a query on an enumerable type, you can
choose what to return. For example, say you have a class with three
properties, FirstName, LastName, and Id. When you perform a query, you can
choose to return a type with just the Id and the LastName. The thing is,
you don't know what that type will be (well, you do, but creating a
compatable type is a pain if you have to do it all the time).

This is where var comes in. It is used along with these anonymous

types

to allow implicit typing (after all, what type would you use for the
anonymous type you just created).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

The C# 3.0 spec (http://msdn.microsoft.com/vcsharp/future/) contains a
feature called "Implicitly typed local variables".

The type of the variable is determined at compile time based on the
expression to the right of the = sign:

var s = "Hello"; //s is strongly typed to be a string
var i = 25; //i is strongly typed to be an integer

But what I don't understand what advantage it is?

string s = "Hello"; //This is just as easy to type and is easier to
read

What's the story?

 

[Daniel Jin]

I'm pretty sure that won't work. I think everything still have to be
strongly typed, meaning all types have to be known (or inferred) at
compile time, may it be an anonymous type or not.

that's why even in the local scope, you can do

var i = 1.0;

but just

var i;

is illegal since you can't implicitly tell what's the type for i.

 

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

William,

This really wouldn't work. With a representation of an anonymous type
like that, you are making it a CLR operation (since you have created a
construct BCL which represents it now), which it isn't. When you compile
with var, it is actually creating a type definition for you, and
substituting that type in compiled assembly.

If you had a .NET representation of an anonymous type, then you are
making it the CLR's responsibility, which would be unecessary.

With the var keyword, they can get the compiler to do all of the work
for them, and not impact the CLR too much.

As a matter of fact, most of the things that are being shown in C# 3.0
are not CLR enhancements, but "compiler trickery". Anders likes to do this,
from what I have seen (anonymous delegates being the first form of it in C#
2.0).

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Customer[] customers = GetCustomers();
var custs = customers.Where(c => c.City == "Seattle").Select(c =>
c.Name);

Or, as C# 3.0 would support it:

Customer[] customers = GetCustomers();
var custs = from c in customers where c.City == "Seattle" select c.Name

Since the new type would only have Name as a property, it can't be of
type Customer. It is anonymous, and you need a way of saying "hey, I
have this strongly-typed thingie over here, but I don't know what it's
named. I know what it does, but you take care of the name, and tell me if
I do something with it that's funky".

Thanks Nicholas. But why not write it like below:

Customer[] customers = GetCustomers();
AType custs = from c in customes where c.City == "Seattle" select c.Name

AType is not some type I created, but the System's Anonomous Type class.
"custs" is still an anonymous type, but it is more direct what we are
taking about and potentially less confusing. There must be a reason they
wanted that "var" keyword.

 

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

Sorry, I meant to say projections, not permutations.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Chris,

The reason this was introduced was to support LINQ, for permutations on
queries. Basically, when performing a query on an enumerable type, you
can choose what to return. For example, say you have a class with three
properties, FirstName, LastName, and Id. When you perform a query, you
can choose to return a type with just the Id and the LastName. The thing
is, you don't know what that type will be (well, you do, but creating a
compatable type is a pain if you have to do it all the time).

This is where var comes in. It is used along with these anonymous
types to allow implicit typing (after all, what type would you use for the
anonymous type you just created).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

The C# 3.0 spec (http://msdn.microsoft.com/vcsharp/future/) contains a
feature called "Implicitly typed local variables".

The type of the variable is determined at compile time based on the
expression to the right of the = sign:

var s = "Hello"; //s is strongly typed to be a string
var i = 25; //i is strongly typed to be an integer

But what I don't understand what advantage it is?

string s = "Hello"; //This is just as easy to type and is easier to
read

What's the story?

 

[William Stacey [MVP]]

I see the light. Thanks Nicholas!

--
William Stacey [MVP]

William,

This really wouldn't work. With a representation of an anonymous type
like that, you are making it a CLR operation (since you have created a
construct BCL which represents it now), which it isn't. When you compile
with var, it is actually creating a type definition for you, and
substituting that type in compiled assembly.

If you had a .NET representation of an anonymous type, then you are
making it the CLR's responsibility, which would be unecessary.

With the var keyword, they can get the compiler to do all of the work
for them, and not impact the CLR too much.

As a matter of fact, most of the things that are being shown in C# 3.0
are not CLR enhancements, but "compiler trickery". Anders likes to do
this, from what I have seen (anonymous delegates being the first form of
it in C# 2.0).

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Customer[] customers = GetCustomers();
var custs = customers.Where(c => c.City == "Seattle").Select(c =>
c.Name);

Or, as C# 3.0 would support it:

Customer[] customers = GetCustomers();
var custs = from c in customers where c.City == "Seattle" select c.Name

Since the new type would only have Name as a property, it can't be of
type Customer. It is anonymous, and you need a way of saying "hey, I
have this strongly-typed thingie over here, but I don't know what it's
named. I know what it does, but you take care of the name, and tell me
if I do something with it that's funky".

Thanks Nicholas. But why not write it like below:

Customer[] customers = GetCustomers();
AType custs = from c in customes where c.City == "Seattle" select c.Name

AType is not some type I created, but the System's Anonomous Type class.
"custs" is still an anonymous type, but it is more direct what we are
taking about and potentially less confusing. There must be a reason they
wanted that "var" keyword.

 

[Helge Jensen]

The C# 3.0 spec (http://msdn.microsoft.com/vcsharp/future/) contains a
feature called "Implicitly typed local variables".
Nice!

var s = "Hello"; //s is strongly typed to be a string
var i = 25; //i is strongly typed to be an integer

But what I don't understand what advantage it is?

I've been wishing for that for quite a while, I have never understood
why modern languages need to be spoon-fed type-declarations. The
compiler must to type-inference on expressions anyway.

There really is no point in declaring static types of local variables,
except if the programmer wish to constrain available operations or make
a note of what type a variable is.

Declaring the type of local storage is really an inherited trait, back
from C, and C got it because compilers weren't that advanced back then
and C programs needed to calculate how much the stack-pointer should move.

 

[Peter Sestoft]

The C# 3.0 spec (http://msdn.microsoft.com/vcsharp/future/) contains a
feature called "Implicitly typed local variables".

The type of the variable is determined at compile time based on the
expression to the right of the = sign:

var s = "Hello"; //s is strongly typed to be a string
var i = 25; //i is strongly typed to be an integer

But what I don't understand what advantage it is?

string s = "Hello"; //This is just as easy to type and is easier to
read

What's the story?

One of the open files in my editor contains this code:

IDictionary<int, IDictionary<String, int>> newtrans =
new HashDictionary<int, IDictionary<String, int>>();
foreach (KeyValuePair<Set<int>, IDictionary<String, Set<int>>> entry in trans)
{
Set<int> k = entry.Key;
IDictionary<String, int> newktrans = new
HashDictionary<String, int>();
foreach (KeyValuePair<String, Set<int>> tr in entry.Value)
newktrans.Add(tr.Key, renamer[tr.Value]);
newtrans.Add(renamer[k], newktrans);
}

Note the atrocious redundancy of type declarations.

With the new "var" feature, one could write instead:

var newtrans = new HashDictionary<int, IDictionary<String, int>>();
foreach (var entry in trans) {
Set<int> k = entry.Key;
var newktrans = new HashDictionary<String, int>();
foreach (var tr in entry.Value)
newktrans.Add(tr.Key, renamer[tr.Value]);
newtrans.Add(renamer[k], newktrans);
}

Peter

 

[Jon Skeet [C# MVP]]

I've been wishing for that for quite a while, I have never understood
why modern languages need to be spoon-fed type-declarations. The
compiler must to type-inference on expressions anyway.

I'm not sure it's so much for the compiler's benefit as for the
reader's. Certainly if I'm reading some code, I want to know the types
of all the variables involved. The fewer potential causes for error,
the better.

I can see the point for anonymous types, but you won't catch me using
them elsewhere.

There really is no point in declaring static types of local variables,
except if the programmer wish to constrain available operations or make
a note of what type a variable is.

Declaring the type of local storage is really an inherited trait, back
from C, and C got it because compilers weren't that advanced back then
and C programs needed to calculate how much the stack-pointer should move.

You need to know the type in order to know what expectations to have.
Suppose I have:

var b = 255;
b++;

What's the value of b now? If b is a byte, it's 0. If b is an int, it's
256. You can easily take the same distinction to ints/longs.