|
No you can't just throw any keyword in there, it has to be a contextual keyword that isn't a keyword in that context.
For example:
using from = System.SByte;
using let = System.Byte;
using orderby = System.Single;
using select = System.String;
|
|
|
|
|
And this also works:
using System;
...
using String = System.Int32;
And:
String s = "str";
String s1 = 5;
|
|
|
|
|
String is not a keyword, so that's not very surprising..
|
|
|
|
|
harold aptroot wrote: String is not a keyword, so that's not very surprising..
Agreed. My first reaction too.
|
|
|
|
|
I kind of had your first responder's reaction to this code, then recalled my irritation with code that used var and forced me to look-up the return type of the function to figure out what the object was. So, my second reaction was YA, someone is forcing the lazy programmer to stop using the lazy var keyword.
I want to kill 'm and sing his/her praises. You could say I'm conflicted.
|
|
|
|
|
If it was the second then they should have linked it to a class called DoNotUseVar or something.
|
|
|
|
|
BobJanova wrote: they should have linked it to a class called DoNotUseVar or something.
 The casting error would certainly pop out better. Less confusing than the unsuspected error generated by:
byte a = 10;
var b = a;
byte c = b;
|
|
|
|
|
I haven't used var except where essential in almost 10 years. 
|
|
|
|
|
I don't like it except in type declaration plus initialise statements ... there's no point doubling up the type information in
var dict = new Dictionary<String, IList<DataColumn>>(); But of course one of the places you can't use it is in field declarations which is where you want to do that a lot!
It's also a bit ugly writing code that saves a Linq query if you declare the type (IQueryable<T>, right?). It seems to be standard to use var there, although I've been known to put the actual type instead.
|
|
|
|
|
BobJanova wrote:
var dict = new Dictionary<String, IList<DataColumn>>();
var columnNameDict = new Dictionary<String, IList<DataColumn>>();
FTFY
Just to ensure that nobody use your dict to find a way to a cathouse. Or something like that.
BTW. I'd like to have this syntax:
Dictionary<String, IList<DataColumn>> dict = new();
I'd have information on type in a more logical place and could concentrate on parameters passed to a constructor. And still no doubling.
Greetings - Jacek
|
|
|
|
|
Yes fair point with the name there. I'd like a type syntax like that (well maybe not exactly like that, it looks a bit weird, but similar) as well, but since we don't and we do have var, it deputises quite well.
|
|
|
|
|
Looks nice, but violates the (already violated) rule that the type of an expression is determined by its parts, not by the context in which it appears.
Of course that rule is already broken by integer constants.. and null cheats with its "null type" that is implicitly convertible to many types.
So I don't know.
|
|
|
|
|
I don't think that's really a rule any more. What's the type of the lambda x => x + 1? You can't tell without looking at the calling context.
|
|
|
|
|
It's still a rule, it just doesn't apply everywhere.
The situation for lambda's is particularly bad[^], but that's no excuse to infect the rest of language with such nonsense.
|
|
|
|
|
BobJanova wrote: But of course one of the places you can't use it is in field declarations which is where you want to do that a lot!
Of course you can! Just do what the original poster had found being done to it.
|
|
|
|
|
Why 10 years? Var was introduced with C# 3.0, which was released about 6 years ago. I hope you weren't trying to use it before then. 
|
|
|
|
|
Long ago, in a galaxy far far away, was something called Visual Basic.
|
|
|
|
|
You are thinking of the VB.NET variant type, which is not the same thing as C#'s implicitly typed "var". In C#, a var variable will have a compile-time type defined by the type on the right hand side of the assignment. In VB.NET, a variant type can change at runtime (unlike in C#).
However, VB.NET now has the ability to implicitly type variables, just as with C#'s var. However, I think in VB.NET, you just do that by leaving off the type (e.g., Dim x = 5).
Variants are an abomination. Implicitly typed variables are necessary (e.g., for anonymous types), and can be nice (e.g., for very long type declarations). You can read more about implicitly typed variables here. The closest thing to VB.NET's variant type in C# would be a variable of type "Object".
|
|
|
|
|
Ah, I see. Thanks for that. Agree, variants are awful; implicit typing? Doesn't sound too helpful for complex walkthrough's, although I love it in Python.
|
|
|
|
|
Not sure what you mean by "complex walkthroughs".
|
|
|
|
|
One job I had meant examining code by eye for the most part. Would have meant a lot of extra difficulty if the variables had not been explicitly declared.
It was a mixture of VC6 and C# interop. The VC6 couldn't be unit tested, it was a 500,000 LOC chunk that could be run through the VS6 debugger, but not split up.
Horrible code.
|
|
|
|
|
Simon O'Riordan from UK wrote: I haven't used var except where essential in almost 10 years.
Wow, you must be really advanced. When I took C# training in 2005 var never came up and I read the manuals from cover to cover and never saw the command. I was under the impression it was introduced in 2005. (I can easily be totally wrong about that.)
When is it ever essential? There is always:
object x = ...
|
|
|
|
|
It was present in Visual Basic. Before .Net was a squirt in a squirts imagination.
|
|
|
|
|
Er, no it wasn't.
VB 6 had variant's but that's a different and altogether more abhorrent kettle of fish[^].
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Yes. We sorted all that out last week. Do try and keep up 007.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
