inferring a type

[John Salerno]

This is something that occurred to me a while ago, and again I was
thinking about it last night. I noticed how redundant it seems to type
an expression like this:

SomeType x = new SomeType();

I asked myself, why do you have to type SomeType twice? I realize the
first is a class name and the second is a constructor, but still it's a
little redundant.

Anyway, coincidentally, I found a video on MSDN with Anders speaking
about a bunch of things, and he happened to bring up this very point. He
said one thing they were considering for C# was this possible syntax:

var x = new SomeType();

and the type of x would be inferred from the 'new' expression. I noticed
that the video was posted in 2004, so I'm wondering, is this some
feature that has snuck into the language since then? If not, why not?

Thanks.

 

[Mattias Sjögren]

John,

I noticed
that the video was posted in 2004, so I'm wondering, is this some
feature that has snuck into the language since then? If not, why not?

Not yet, but it's one of the features they are planning to add in C#
v3.


Mattias

 

[John Richardson]

can't you already do that?
object x = new SomeType();
Perhaps it's not quite the same as using var x as in scripting languages,
but it's pretty close.

But it would make it difficult to figure out which interface you are
implementing. SomeType can be cast to it's inheriting types, or other
implemented interfaces, and you'll have to type the object at that point
anyways, and I'd rather have intellisense help me out. I would be curious
how this feature would work, if in fact they are thinking about it for v3 of
C#.

I read a brilliant quote once from somewhere during a discussion of why you
can't use a type in a switch statement that was something like "Sometimes
the best design is achieved by removing or not designing a feature." (I
think I butured the quote...

 

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

John,

This is nothing close to what var is proposing. With what you have, I
can do this:

object x = new SomeType();
x = 1;
x = "hello";

With var, I can not do that. Additionally, with var, I will have
intellisense support, since the variable is strongly typed.

 

[John Richardson]

Hmm... I decided to read up on this based on your response. I suppose the
var is an interesting idea to implement as far as anonymous types are
concerned. I'm sure it has ramifications that I don't understand yet. But
I'm surprised that there are alot of people that find that typing the class
name twice is so onerous. The cost of typing a little more could be offset
by time spent figuring out the interface of the object declared as var.
There will be people who will get all excited about this feature, and
declare object level variables using the var keyword, and instantiate them
elsewhere, making code readability a total nightmare.

But thank you in correcting my assumption of a typeless var declaration.

John,

This is nothing close to what var is proposing. With what you have, I
can do this:

object x = new SomeType();
x = 1;
x = "hello";

With var, I can not do that. Additionally, with var, I will have
intellisense support, since the variable is strongly typed.


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

can't you already do that?
object x = new SomeType();
Perhaps it's not quite the same as using var x as in scripting languages,
but it's pretty close.

But it would make it difficult to figure out which interface you are
implementing. SomeType can be cast to it's inheriting types, or other
implemented interfaces, and you'll have to type the object at that point
anyways, and I'd rather have intellisense help me out. I would be
curious how this feature would work, if in fact they are thinking about
it for v3 of C#.

I read a brilliant quote once from somewhere during a discussion of why
you can't use a type in a switch statement that was something like
"Sometimes the best design is achieved by removing or not designing a
feature." (I think I butured the quote...

 

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

That's not going to happen. You can not use var outside of a method
implementation (as it stands now). With that, you can't use var to declare
a field in a class.

However, I do agree that it will be abused in a method. I think that
var should be used only when the type name is onerous (some dictionary with
dictionaries in it, for example), or when you are using anonymous types.


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

Hmm... I decided to read up on this based on your response. I suppose the
var is an interesting idea to implement as far as anonymous types are
concerned. I'm sure it has ramifications that I don't understand yet.
But I'm surprised that there are alot of people that find that typing the
class name twice is so onerous. The cost of typing a little more could be
offset by time spent figuring out the interface of the object declared as
var. There will be people who will get all excited about this feature, and
declare object level variables using the var keyword, and instantiate them
elsewhere, making code readability a total nightmare.

But thank you in correcting my assumption of a typeless var declaration.

John,

This is nothing close to what var is proposing. With what you have, I
can do this:

object x = new SomeType();
x = 1;
x = "hello";

With var, I can not do that. Additionally, with var, I will have
intellisense support, since the variable is strongly typed.


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

can't you already do that?
object x = new SomeType();
Perhaps it's not quite the same as using var x as in scripting
languages, but it's pretty close.

But it would make it difficult to figure out which interface you are
implementing. SomeType can be cast to it's inheriting types, or other
implemented interfaces, and you'll have to type the object at that point
anyways, and I'd rather have intellisense help me out. I would be
curious how this feature would work, if in fact they are thinking about
it for v3 of C#.

I read a brilliant quote once from somewhere during a discussion of why
you can't use a type in a switch statement that was something like
"Sometimes the best design is achieved by removing or not designing a
feature." (I think I butured the quote...



This is something that occurred to me a while ago, and again I was
thinking about it last night. I noticed how redundant it seems to type
an expression like this:

SomeType x = new SomeType();

I asked myself, why do you have to type SomeType twice? I realize the
first is a class name and the second is a constructor, but still it's a
little redundant.

Anyway, coincidentally, I found a video on MSDN with Anders speaking
about a bunch of things, and he happened to bring up this very point.
He said one thing they were considering for C# was this possible
syntax:

var x = new SomeType();

and the type of x would be inferred from the 'new' expression. I
noticed that the video was posted in 2004, so I'm wondering, is this
some feature that has snuck into the language since then? If not, why
not?

Thanks.

 

[jeremiah johnson]

However, I do agree that it will be abused in a method. I think that
var should be used only when the type name is onerous (some dictionary with
dictionaries in it, for example), or when you are using anonymous types.

I agree 100%. If you know what your object is going to be before you
code that line, then you use the classname twice:

SomeType st = new SomeType();

if you don't know what it will be, then use var:

var x =
from productTable in products
where partNumber = "5rf700-a"
select productName, productID;

 

[SP]

This is something that occurred to me a while ago, and again I was
thinking about it last night. I noticed how redundant it seems to type an
expression like this:

SomeType x = new SomeType();

I asked myself, why do you have to type SomeType twice? I realize the
first is a class name and the second is a constructor, but still it's a
little redundant.

You don't have to type it twice if you are using VS. Intellisense takes care
of the second SomeType with the press of the tab key.

Not so when you are constructing like

MyBase x = new MyDerived();
IMyClass y = new MyClass();

when Intellisense doesn't give you a list of the just the types that
implement / inherit the declaring type.

SP

 

[John Salerno]

That's not going to happen. You can not use var outside of a method
implementation (as it stands now). With that, you can't use var to declare
a field in a class.

However, I do agree that it will be abused in a method. I think that
var should be used only when the type name is onerous (some dictionary with
dictionaries in it, for example), or when you are using anonymous types.

In fact, it was a dictionary that Anders was using as an example.

 

[John Richardson]

I just watched the Anders interview, and now I understand a bit about the
use of var, and it is incredibly powerful. I wish I'd researched a bit
before my initial reply-post! Using LINQ (and var for a reference to the
result) for database data is going to be a huge time saver, but what was
even more amazing and exciting was the implications on in-memory data, such
as querying an object type, or finding all in-memory textboxes on a given
form. That was not something I expected and is very interesting.

here's the interview for others interested:
http://channel9.msdn.com/showpost.aspx?postid=114680

 

[John Salerno]

I just watched the Anders interview, and now I understand a bit about the
use of var, and it is incredibly powerful. I wish I'd researched a bit
before my initial reply-post! Using LINQ (and var for a reference to the
result) for database data is going to be a huge time saver, but what was
even more amazing and exciting was the implications on in-memory data, such
as querying an object type, or finding all in-memory textboxes on a given
form. That was not something I expected and is very interesting.

here's the interview for others interested:
http://channel9.msdn.com/showpost.aspx?postid=114680

Actually, the one I watched was at
http://msdn.microsoft.com/msdntv/episode.aspx?xml=episodes/en/20040624csharpah/manifest.xml

But yours is shorter and maybe more focused. I'll watch it in a little bit.

 

[Bruce Wood]

There will be people who will get all excited about this feature, and

declare object level variables using the var keyword, and instantiate them
elsewhere, making code readability a total nightmare.

I talked to members of the VS team at PDC'05 and they assured me that
they are already working on ideas for viewing / printing code so that
you can somehow see the type of a variable declared with "var", just as
you could before "var".

Of course, this won't help you if you're not using the IDE, or print
your code from some other place than from the IDE.

 

[John Salerno]

I just watched the Anders interview, and now I understand a bit about the
use of var, and it is incredibly powerful. I wish I'd researched a bit
before my initial reply-post! Using LINQ (and var for a reference to the
result) for database data is going to be a huge time saver, but what was
even more amazing and exciting was the implications on in-memory data, such
as querying an object type, or finding all in-memory textboxes on a given
form. That was not something I expected and is very interesting.

here's the interview for others interested:
http://channel9.msdn.com/showpost.aspx?postid=114680

Wow, this video is fascinating, and I don't even know much about SQL or
database programming. Somehow, Anders has a way of explaining things
that make them seem so simple!

 

[Jon Skeet [C# MVP]]

Not yet, but it's one of the features they are planning to add in C#
v3.

Yes, although the main reason for that (I believe) is to support
anonymous types. I would recommend against using it for "normal" types
- unless perhaps they're hugely long generic names (eg
List<Map<string,List<int>>>)