C# 3.0 Proposals

[Guest]

Where can I go to state my views for or against some of the C# 3.0 proposals?

They are listed here:

http://download.microsoft.com/downl...a45-a3803d8134b8/CSharp_3.0_Specification.doc

For one thing, I can not believe they are trying to convert C# to VB by
making it a non-type safe language. For an example of what I mean read this
excerpt from the doc:

"26.1 Implicitly typed local variables
In an implicitly typed local variable declaration, the type of the local
variable being declared is inferred from the expression used to initialize
the variable. When a local variable declaration specifies var as the type and
no type named var is in scope, the declaration is an implicitly typed local
variable declaration. For example:

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

I don't know about you guys, but that just smells too much like VB's variant
type. NASTY!!

 

[Mythran]

Where can I go to state my views for or against some of the C# 3.0
proposals?

They are listed here:

http://download.microsoft.com/downl...a45-a3803d8134b8/CSharp_3.0_Specification.doc

For one thing, I can not believe they are trying to convert C# to VB by
making it a non-type safe language. For an example of what I mean read
this
excerpt from the doc:

"26.1 Implicitly typed local variables
In an implicitly typed local variable declaration, the type of the local
variable being declared is inferred from the expression used to initialize
the variable. When a local variable declaration specifies var as the type
and
no type named var is in scope, the declaration is an implicitly typed
local
variable declaration. For example:

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

I don't know about you guys, but that just smells too much like VB's
variant
type. NASTY!!

I see this mis-conception by a lot of developers. It is *NOT* an untyped
variable (variant). Those are, in face, typed. For example:

var i = 5;

This creates i as an integer and assigns the integer 5 to it. If you later
decide to assign a string, or other non-integral data to it, then you would
get a type exception.

var i = 5;
i = "test"; <-- results in an exception being thrown because you can't
assign a string to an integer.

If you read further about the language integrated query stuff, you should
see that the "var" keyword is something that is needed for LIQ to function
properly

HTH,
Mythran

 

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

Demetri,

In reality, it is nothing like vb's variant type. For example, you can
not do this:

var stringVariable = "hello there";
var numberVariable = 0;

// This line throws a compiler error.
numberVariable = stringVariable;

As you pointed out in the section that you copied and pasted, it is an
^implicitly^ typed local variable. This doesn't mean that it is not strong
typed, it just means that it is not explicitly typed, like so:

string stringVariable = "hello there";
int numberVariable = 0;

Hope this helps.

 

[Guest]

So then what is wrong with boxing using the object type. I'm assuming this
"implicit" typing is there to allow one to assign a type that is not known
during design time?

Isn't var x = 1; essentially the same as object x = 1; ?

In BOTH cases if I want to add another number to x then I must know before
hand that what i'm adding is of type int, correct?

You may argue, well you may not know that what you're adding is an int, but
I argue that you will need to know somewhat in order to know that you CAN add
the to mathematically.

So i'm not sold on this var (implicit) typing thing. I certainly hope its
not a "workaround" to appease LINQ. Constructing a language to communicate
with one set of technolgies in mind is a bad plan in my estimation.

--
-Demetri

Demetri,

In reality, it is nothing like vb's variant type. For example, you can
not do this:

var stringVariable = "hello there";
var numberVariable = 0;

// This line throws a compiler error.
numberVariable = stringVariable;

As you pointed out in the section that you copied and pasted, it is an
^implicitly^ typed local variable. This doesn't mean that it is not strong
typed, it just means that it is not explicitly typed, like so:

string stringVariable = "hello there";
int numberVariable = 0;

Hope this helps.


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

Where can I go to state my views for or against some of the C# 3.0
proposals?

They are listed here:

http://download.microsoft.com/downl...a45-a3803d8134b8/CSharp_3.0_Specification.doc

For one thing, I can not believe they are trying to convert C# to VB by
making it a non-type safe language. For an example of what I mean read
this
excerpt from the doc:

"26.1 Implicitly typed local variables
In an implicitly typed local variable declaration, the type of the local
variable being declared is inferred from the expression used to initialize
the variable. When a local variable declaration specifies var as the type
and
no type named var is in scope, the declaration is an implicitly typed
local
variable declaration. For example:

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

I don't know about you guys, but that just smells too much like VB's
variant
type. NASTY!!

 

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

Demetri,

See inline:

So then what is wrong with boxing using the object type. I'm assuming this
"implicit" typing is there to allow one to assign a type that is not known
during design time?

Isn't var x = 1; essentially the same as object x = 1; ?

The compiler has to know the type at compile time. When you use object,
it will box, but it will not box with var. Rather, that x is an int, and
you can not assign anything else to it.

Implicit means that it is assumed what the type is, not that it can hold
any type.

Just like you can do this:

double d = 10;

10 is technically an integer, but it is implicitly cast to a double.

In BOTH cases if I want to add another number to x then I must know before
hand that what i'm adding is of type int, correct?

Yes, you must, or have a type that is able to be implicitly cast to int.
The difference with:

object x = 1;

Is that you can then do:

x = "hey";

Whereas with var, you can't do it, you will get a compiler error.

You may argue, well you may not know that what you're adding is an int,
but
I argue that you will need to know somewhat in order to know that you CAN
add
the to mathematically.

There is no argument. With var, if you assign an int, it is an int, you
can't assign anything else to the variable. It is type-safe and the
compiler will verify that.

So i'm not sold on this var (implicit) typing thing. I certainly hope its
not a "workaround" to appease LINQ. Constructing a language to communicate
with one set of technolgies in mind is a bad plan in my estimation.

Actually, LINQ in itself doesn't communicate with one set of
technologies. It is DLINQ that does that. However, var is something that
is needed for LINQ to be utilized, yes.

Just try and compile this:

var x = 10;
x = "some string";

And then tell me how x is not type-safe. It might be ambiguous, but it
is definitely type-safe.


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

--
-Demetri

Demetri,

In reality, it is nothing like vb's variant type. For example, you
can
not do this:

var stringVariable = "hello there";
var numberVariable = 0;

// This line throws a compiler error.
numberVariable = stringVariable;

As you pointed out in the section that you copied and pasted, it is
an
^implicitly^ typed local variable. This doesn't mean that it is not
strong
typed, it just means that it is not explicitly typed, like so:

string stringVariable = "hello there";
int numberVariable = 0;

Hope this helps.


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

Where can I go to state my views for or against some of the C# 3.0
proposals?

They are listed here:

http://download.microsoft.com/downl...a45-a3803d8134b8/CSharp_3.0_Specification.doc

For one thing, I can not believe they are trying to convert C# to VB by
making it a non-type safe language. For an example of what I mean read
this
excerpt from the doc:

"26.1 Implicitly typed local variables
In an implicitly typed local variable declaration, the type of the
local
variable being declared is inferred from the expression used to
initialize
the variable. When a local variable declaration specifies var as the
type
and
no type named var is in scope, the declaration is an implicitly typed
local
variable declaration. For example:

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

I don't know about you guys, but that just smells too much like VB's
variant
type. NASTY!!

 

[Guest]

Ok, I understand. I believe the root of the stir and mis-conceptions is the
keyword "var" itself. Short for variant?

Perhaps they should think about giving it a better name? One that doesn't
sound so much like VB's variant type.


-Demetri

Demetri,

See inline:

So then what is wrong with boxing using the object type. I'm assuming this
"implicit" typing is there to allow one to assign a type that is not known
during design time?

Isn't var x = 1; essentially the same as object x = 1; ?

The compiler has to know the type at compile time. When you use object,
it will box, but it will not box with var. Rather, that x is an int, and
you can not assign anything else to it.

Implicit means that it is assumed what the type is, not that it can hold
any type.

Just like you can do this:

double d = 10;

10 is technically an integer, but it is implicitly cast to a double.

In BOTH cases if I want to add another number to x then I must know before
hand that what i'm adding is of type int, correct?

Yes, you must, or have a type that is able to be implicitly cast to int.
The difference with:

object x = 1;

Is that you can then do:

x = "hey";

Whereas with var, you can't do it, you will get a compiler error.

You may argue, well you may not know that what you're adding is an int,
but
I argue that you will need to know somewhat in order to know that you CAN
add
the to mathematically.

There is no argument. With var, if you assign an int, it is an int, you
can't assign anything else to the variable. It is type-safe and the
compiler will verify that.

So i'm not sold on this var (implicit) typing thing. I certainly hope its
not a "workaround" to appease LINQ. Constructing a language to communicate
with one set of technolgies in mind is a bad plan in my estimation.

Actually, LINQ in itself doesn't communicate with one set of
technologies. It is DLINQ that does that. However, var is something that
is needed for LINQ to be utilized, yes.

Just try and compile this:

var x = 10;
x = "some string";

And then tell me how x is not type-safe. It might be ambiguous, but it
is definitely type-safe.


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

--
-Demetri

Demetri,

In reality, it is nothing like vb's variant type. For example, you
can
not do this:

var stringVariable = "hello there";
var numberVariable = 0;

// This line throws a compiler error.
numberVariable = stringVariable;

As you pointed out in the section that you copied and pasted, it is
an
^implicitly^ typed local variable. This doesn't mean that it is not
strong
typed, it just means that it is not explicitly typed, like so:

string stringVariable = "hello there";
int numberVariable = 0;

Hope this helps.


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

Where can I go to state my views for or against some of the C# 3.0
proposals?

They are listed here:

http://download.microsoft.com/downl...a45-a3803d8134b8/CSharp_3.0_Specification.doc

For one thing, I can not believe they are trying to convert C# to VB by
making it a non-type safe language. For an example of what I mean read
this
excerpt from the doc:

"26.1 Implicitly typed local variables
In an implicitly typed local variable declaration, the type of the
local
variable being declared is inferred from the expression used to
initialize
the variable. When a local variable declaration specifies var as the
type
and
no type named var is in scope, the declaration is an implicitly typed
local
variable declaration. For example:

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

I don't know about you guys, but that just smells too much like VB's
variant
type. NASTY!!

 

[Guest]

You're right. And I can see the naming conventions regressing back to the
silly ole pefixes for variable names such as
strMyString,intMyInteger,objMyObject, etc. I hated seeing people doing that
in a strongly typed language.

It's just unecessarly redundant in my opinion. If your method is so long you
have to scroll back up to see what the type of the variable is that you need
to use then your method is poorly factored (designed) and should not be more
than a screen length. Of course some exceptions apply but as a general rule.

 

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

Demetri,

This is true, and I agree with you. However, var is necessary when you
use anonymous types:

var x = new {MyField = 10; MyString = "Hey There"};

I would slap anyone that I see do this:

var x = 10;

Because you know the type.

 

[Guest]

Nicholas,

I'm still not quite sold 100%. Entertain me a little further.

What is the benefit of doing this:

var x = new {MyField = 10; MyString = "Hey There"};

And using a struct, which is a new value type anyway, no?

Either way, at some point you will HAVE to know what type you are dealing
with. I don't see much of a way around it. In your example above, how do I
then use x to reference the values it contains? Won't I still have to know
that MyField is an int and MyString is a string? I still don't see what
anonymous types are really buying you compared with what the current C#
version offers.

--
-Demetri

Demetri,

This is true, and I agree with you. However, var is necessary when you
use anonymous types:

var x = new {MyField = 10; MyString = "Hey There"};

I would slap anyone that I see do this:

var x = 10;

Because you know the type.

 

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

Demetri,

Well, in this case, it is a new class, not a new struct, but that's not
what is important in this conversation.

When you use the example I created, it creates a type that has scope
only in the method/property you define it in. It doesn't have scope outside
of it. Sometimes, it is easier to have that. To access those fields, you
would just do this:

var x = new {MyField = 10; MyString = "Hey There"};
int i = x.MyField;

You would access the field like any other field. x is a fully fledged
type and is subject to the same rules as any other type.

Now, why would you want something like this? Well, in LINQ, you can do
projections, which means that it will allow you to access a subset of
information in the set that is returned, so if you are selecting over say,
the FileInfo instances, you can return just the name, and the directory that
it came from, instead of all the info in the FileInfo instance.


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

Nicholas,

I'm still not quite sold 100%. Entertain me a little further.

What is the benefit of doing this:

var x = new {MyField = 10; MyString = "Hey There"};

And using a struct, which is a new value type anyway, no?

Either way, at some point you will HAVE to know what type you are dealing
with. I don't see much of a way around it. In your example above, how do I
then use x to reference the values it contains? Won't I still have to know
that MyField is an int and MyString is a string? I still don't see what
anonymous types are really buying you compared with what the current C#
version offers.

--
-Demetri

Demetri,

This is true, and I agree with you. However, var is necessary when
you
use anonymous types:

var x = new {MyField = 10; MyString = "Hey There"};

I would slap anyone that I see do this:

var x = 10;

Because you know the type.


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

You're right. And I can see the naming conventions regressing back to
the
silly ole pefixes for variable names such as
strMyString,intMyInteger,objMyObject, etc. I hated seeing people doing
that
in a strongly typed language.

It's just unecessarly redundant in my opinion. If your method is so
long
you
have to scroll back up to see what the type of the variable is that you
need
to use then your method is poorly factored (designed) and should not be
more
than a screen length. Of course some exceptions apply but as a general
rule.

--
-Demetri


:

Demetri wrote:
So then what is wrong with boxing using the object type. I'm
assuming
this
"implicit" typing is there to allow one to assign a type that is not
known
during design time?

Isn't var x = 1; essentially the same as object x = 1; ?

No. var x is an int value, object x is a boxed value.

E.g.:

var x = 1; x++; // is valid code
object x = 1; x++; // is invalid code


var x = 1.0 for example compiles to double x = 1.0



In BOTH cases if I want to add another number to x then I must know
before
hand that what i'm adding is of type int, correct?

No. With var the type is specified and cannot be changed, like that
would be the case for a variant.

You may argue, well you may not know that what you're adding is an
int,
but
I argue that you will need to know somewhat in order to know that
you
CAN add
the to mathematically.

Good argument, but the compiler knows - even if you aren't sure about
it
what type the variable is. Why should you know ? (in this case).


So i'm not sold on this var (implicit) typing thing. I certainly
hope
its
not a "workaround" to appease LINQ. Constructing a language to
communicate
with one set of technolgies in mind is a bad plan in my estimation.

Anonymous types are needed for e.g. anonymous structures:

E.g.:

var s = new { a = 10, b = 1.2 };

Creates implicitly a structure with a hidden name. You haven't defined
the structure so you cannot use a type name.


I find var very convenient. E.g. if I don't have to care about type
returned by a function I simply can write:

var result = function();
function2(result);

Instead of:

MyObjectNameButToLong result = function();
function2(result);


Though I must admit that the code is somewhat harder to interpret. So
I
wouldn't exceed the usage of var and use it only where it makes sense,
must be used and where it doesn't makes the code much harder to read /
interpret.

Andre

 

[Dan Manges]

Nicholas,

I'm still not quite sold 100%. Entertain me a little further.

What is the benefit of doing this:

var x = new {MyField = 10; MyString = "Hey There"};

And using a struct, which is a new value type anyway, no?

Either way, at some point you will HAVE to know what type you are dealing
with. I don't see much of a way around it. In your example above, how do I
then use x to reference the values it contains? Won't I still have to know
that MyField is an int and MyString is a string? I still don't see what
anonymous types are really buying you compared with what the current C#
version offers.

Demetri,

One advantage is you don't have to have a class to store an object with
the attributes you want. The most applicable example I can think of is
with a database. Right now NHibernate requires a class for each
database table. With C# 3.0, having an actual class won't be necessary
as the object can be created like in the example you gave.

Ruby on Rails with ActiveRecord is the best example I can think of using
this feature this way.

Dan Manges

 

[Chris Dunaway]

Take a look at this video, it will explain a lot:

http://channel9.msdn.com/showpost.aspx?postid=114680

 

[Lucian Wischik]

Ok, I understand. I believe the root of the stir and mis-conceptions is the
keyword "var" itself. Short for variant?

Short for "variable", I'd guess...

 

[Lucian Wischik]

var x = new {MyField = 10; MyString = "Hey There"};

Consider this code:

var x = new {MyTag=...; x=10; y=15};
return x;

Versus the following code, which is how you'd write it in C#2 if you
were obeying all the good design practices of object-oriented
programming (never expose plain fields; use properties; use
descriptive variable names; ...) and the suggestions of FxCop:

public struct TaggedPoint
{ int p_XCoordinate;
int p_YCoordinate;
ReadOnlyCollection<string> p_Tags;

public int XCoordinate
{ get {return p_XCoordinate;}
set {p_XCoordinate=value;}
}
public int YCoordinate
{ get {return p_YCoordinate;}
set {p_YCoordinate=value;}
}
public IList<string> Tags
{ get {return p_Tags;}
set {p_Tags=new ReadOnlyCollection<string>(new
List<string>(value));}
}

public override bool Equals(object obj)
{ if (!(obj is TaggedPoint)) return false;
return this==(TaggedPoint)obj;
}
public bool Equals(TaggedPoint tp)
{ return this==tp;
}
public static bool operator ==(TaggedPoint p1,TaggedPoint p2)
{ return p1.p_XCoordinate == p2.p_XCoordinate
&& p1.p_YCoordinate == p2.p_YCoordinate
&& p1.p_Tags.Equals(p2.p_Tags);
}
public static bool operator !=(TaggedPoint p1,TaggedPoint p2)
{ return !(p1==p2);
}
public override int GetHashCode()
{ return p_XCoordinate.GetHashCode()
^ p_YCoordinate.GetHashCode()
^ p_Tags.GetHashCode();
}
}



static public TaggedPoint Test()
{ List<string> tags=new List<string>(); tags.Add("hello");
tags.Add("world");
TaggedPoint tp = new TaggedPoint();
tp.XCoordinate=10; tp.YCoordinate=15; tp.Tags=tags;
return tp;
}

 

[Alan Pretre]

Ok, I understand. I believe the root of the stir and mis-conceptions is
the
keyword "var" itself. Short for variant?

Perhaps they should think about giving it a better name? One that doesn't
sound so much like VB's variant type.

"var" is used in jscript. I think it came from there. It means a variable,
not a variant.

-- Alan

 

[Barry Kelly]

"var" is used in jscript. I think it came from there. It means a variable,
not a variant.

It's short for variable, and it seems to me that it came from Pascal -
but then I have a Pascal background.

Also, JScript variables are effectively variants, but C# 3.0 'var'
variables are strongly typed.

-- Barry

 

[Otis Mukinfus]

Demetri,

See inline:

And then tell me how x is not type-safe. It might be ambiguous, but it
is definitely type-safe.

Being ambiguous is precisely what is wrong with it....

Suppose I use the implicit declaration like this:

var d = 10; // double but the compiler will probably think it's int32

var i = 10; // int32 but the compiler will probably think it's int32

var j = 10; // int64 but the compiler will probably think it's int32


Now, when I'm 600 lines down in my code I won't know which is declared as what.


What a wonderful idea. Now we can all have the same fun we had in 1996 again.

Good luck with your project,

Otis Mukinfus
http://www.arltex.com
http://www.tomchilders.com

 

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

Lucian,

You would never write that code. The type of x only has meaning inside
the method that it is declared in.

The only way you could access x would be to return object, and on top of
that, use reflection to access the fields.

You would pretty much NEVER do this.

 

[Barry Kelly]

Being ambiguous is precisely what is wrong with it....

It's not ambiguous at all. Every expression has a type, constructed from
the bottom up.

Suppose I use the implicit declaration like this:

var d = 10; // double but the compiler will probably think it's int32
var i = 10; // int32 but the compiler will probably think it's int32
var j = 10; // int64 but the compiler will probably think it's int32

These aren't ambiguous at all. '10' is an integer constant expression of
type Int32. For example:

---8<---
Console.WriteLine(10.GetType().Name); // prints Int32
--->8---

If and only if a constant expression evaluates to an Int32 within the
range of a smaller type like byte, sbyte, short or ushort, then it's
assignable to a variable of that type.

Again:

---8<---
double d = 10;
--->8---

Here '10' is still an Int32. Int32 happens to have an implicit
conversion to type Double, but 10 is still an Int32. 'var' permits you
to:

1. Create a variable of an anonymous type.
2. Avoid repetition when instantiating a complex generic type.
3. Remove unnecessary explicit type annotation when receiving the return
value of methods or other expressions.

Case by case:

1) 'var' is absolutely needed here.
2) 'var' is a blessing here - code is needlessly wordy currently,
especially for instantiating Dictionary<,> or other classes that take
more than one type argument.
3) The return type can already be used once in an expression without
naming the type - directly:

typeof(Int32).ToString().Length

Are you annoyed right now that you don't have to explicitly annotate the
return type of the ToString() method? If you aren't, then why would you
be annoyed with using 'var' to declare a variable that receives this
value? You're simply propagating the same information to somewhere else.
In every real program the value of an expression will have a semantic
name that is more meaningful than the type annotation anyway. In many
ways, the existing type annotations in variable declarations are similar
to the old Hungarian notation.

Here's another example:

---8<---
Console.WriteLine((40 + 1.5).GetType().Name);
--->8---

Does it bother you that this is currently legal code? The values of
expressions are already usable where the type isn't directly annotated.
Adding 'var' simply allows reusing these values without the need to add
type annotation.

It isn't a replacement for variable declarations that need to be of a
specific type! You still need to be explicit where you need to be. It
simply removes the need to be explicit when you don't need it, and even
better when being explicit is impossible.

-- Barry

 

[Rune Huseby]

Being ambiguous is precisely what is wrong with it....

Suppose I use the implicit declaration like this:

var d = 10; // double but the compiler will probably think it's int32
var i = 10; // int32 but the compiler will probably think it's int32
var j = 10; // int64 but the compiler will probably think it's int32

The compilers will not think it's int32, it will know it is int32. Since
10 _is_ int32.

Use suffixes to indicate type in constants:
var d = 10d; // double and the compiler will know it's double
var i = 10; // int32 and the compiler will know it's int32
var j = 10l; // int64 and the compiler will know it's int64

The suffixes you can use are:
l or L for long
u or U for unsigned
d or D for double
f or F for float
m or M for decimal

There is not suffix for short or byte

On the other hand, I would be sceptical about code the uses 'var' like
this.