C# 3.0 Proposals

[Andre Kaufmann]

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 Holmes]

.... snipped much

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

so for instance this is now possible?

class Parameter { }
class Parameter<T> : Parameter {
private T _value ;
Parameter (T value)
{ _value = value;}
}

List<Parameter> l = new List<Parameter> ();

l.Add(new Parameter<string>("asdf"));
l.Add(new Parameter<int>(10));

foreach (var p in l)
{
//in here var is typed correctly?
}

 

[Barry Kelly]

List<Parameter> l = new List<Parameter> ();

l.Add(new Parameter<string>("asdf"));
l.Add(new Parameter<int>(10));

foreach (var p in l)
{
//in here var is typed correctly?
}

Should be type to Parameter, yes.

-- Barry

 

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

Dan,

That should be possible now.

 

[Ole Nielsby]

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

IMO these implicitly typed declarations should be readonly,
and for that, "var" would be slightly misleading. Maybe "let"???

I would still allow their use in foreach(let x in ...), the cardinal
point being that there should never be two textually distinct
assignments.

If a programmer wants to assign to a variable in many places,
the effects of these assignments should be clarified by explicitly
typing the variable. However if the defining assignment is the
only one, no type conversions will be introduced and implicit
typing is fine.

A shorthand for readonly variables would encourage a
programming style that is less dependent on the order in
which things are done, which is good both for optimizers
and for code robustness.

Ole N.

 

[Bruce Wood]

If your method is so long you have to scroll back up to see what the type of the variable is...

You're forgetting one thing that for me makes all of the difference:
all of this is taking place within an IDE that will _tell_ you the type
of the variable if you just mouse over it.

Without the IDE, "var" would be a nightmare. Subtle touches like
whether you say:

var x = 10;

or

var x = 10l;

change everything. Now, granted, this is an ugly use of "var", but the
point is that without the IDE it becomes difficult to know what's going
on. Without the IDE I would be against the use of "var" except in cases
where it's essential. Fortunately, we live in a modern world with an
IDE, so I don't have to scroll anywhere to find out the type of a
variable. I just ask the oracle and it tells me.

Of course, the rub is printed copy--where the IDE can't help me--but
then I don't print out source code much any more.

 

[Otis Mukinfus]

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.

After thinking this over, I do see one advantage to this. It would certainly
make conversion of java code to C# code easier. I suspect that is the real
reason behind the proposal. Along with making it easier for VB and Java
programmers to avoid learning type safe programming.

Your example of using suffixes to define the type is, in my opinion, the same as
explicitly declaring the type. Why should one have to resort to that method of
sidestepping the issue of the compiler not being able to determine the type in
the example I gave.

Appending d to 10 saved you 5 characters of typing and appending l saved you 3,
but as I said in my first post without the suffixes the compiler would interpret
all of them as int32.

Contractors specializing in bug fixes will make a lot of money off that change.

In addition to this proposal I think it should also be mandatory to prefix all
variable names with something like spzs, str, int, dbl, pint etc., etc. ;o)


Good luck with your project,

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

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

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

I also have a Pascal background, and to me it seems more likely that the
var keyword is more inspired by JScript than Pascal.

The proposed usage is identical in syntax with the use in JScript, while
it's used differently in Pascal.

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

After thinking this over, I do see one advantage to this. It would certainly
make conversion of java code to C# code easier. I suspect that is the real
reason behind the proposal. Along with making it easier for VB and Java
programmers to avoid learning type safe programming.

Your example of using suffixes to define the type is, in my opinion, the same as
explicitly declaring the type.

Yes, of course it is. That's why the var keyword should not be used that
way. It should be used where the data type is obvious, and where it
actually makes the code easier to read. Like this:

var img = new System.Drawing.Image();

as opposed to:

System.Drawing.Image img = new System.Drawing.Image();

Why should one have to resort to that method of
sidestepping the issue of the compiler not being able to determine the type in
the example I gave.

The compiler can determine the type just fine. It's not the compilers
fault that you didn't write what you intended.

Appending d to 10 saved you 5 characters of typing

No. 2 characters.

and appending l saved you 3,

No. 0 characters.

but as I said in my first post without the suffixes the compiler would interpret
all of them as int32.

Contractors specializing in bug fixes will make a lot of money off that change.

No, not if it's used well. Badly written code can easily be created
using the current version of C#, or any language for that matter. A
programming language never creates bad code, bad programmers do.

If this addition to the C# language would be such a huge problem, then
the entire VB language would be a disaster.

In addition to this proposal I think it should also be mandatory to prefix all
variable names with something like spzs, str, int, dbl, pint etc., etc. ;o)

Yes, hungarian notation would be needed if the change really did make
the language non type safe. In languages like VBscript, where there is
no type safety at all, it's needed to survive.

 

[Barry Kelly]

I also have a Pascal background, and to me it seems more likely that the
var keyword is more inspired by JScript than Pascal.

I would argue that the 'var' syntax in JavaScript also comes from
Pascal. It uses some other things, such as 'function', and the
tentative new syntax for EcmaScript (i.e. something similar to
JScript.NET) uses type annotations using ': <type>' style, from Pascal.

For example, here is a little bit of JScript.net (compile with jsc):

---8<---
import System;

// This header line looks very Pascal-ish to me
function Double(x: int): int
{
return x * 2;
}

Console.WriteLine(Double(5));
--->8---

The proposed usage is identical in syntax with the use in JScript, while
it's used differently in Pascal.

It is used in a statement context, rather in a declaration block. I'll
just contend that JavaScript borrows a (small) chunk of stuff from
Pascal.

-- Barry

 

[Barry Kelly]

After thinking this over, I do see one advantage to this. It would certainly
make conversion of java code to C# code easier. I suspect that is the real
reason behind the proposal. Along with making it easier for VB and Java
programmers to avoid learning type safe programming.

I think you are confusing JavaScript and Java

-- Barry

 

[Martin Carpella]

After thinking this over, I do see one advantage to this. It would certainly
make conversion of java code to C# code easier. I suspect that is the real
reason behind the proposal. Along with making it easier for VB and Java
programmers to avoid learning type safe programming.

The "real" reason for proposing this is the introduction of anonymous
types which are required by LINQ (the integrated query language), which
you could not refer to otherwise as anonymous types obviously do not
have a name.

Best regards,
Martin