C#'s sneaky typedef
-
I was completely flabbergasted by a piece of C# code, until I saw one line near the top (hidden at first in a collapsed block) that read
using var = System.Int32;
Wow, OK. Yes, you can do that, and yes, that makes var (note the colour) behave exactly like int (well like Int32 really - that is, you can't use it as the base type of an enum), and yes, this forum is highlighting it with the wrong colour in the code block.
-
I was completely flabbergasted by a piece of C# code, until I saw one line near the top (hidden at first in a collapsed block) that read
using var = System.Int32;
Wow, OK. Yes, you can do that, and yes, that makes var (note the colour) behave exactly like int (well like Int32 really - that is, you can't use it as the base type of an enum), and yes, this forum is highlighting it with the wrong colour in the code block.
Find them. Then kill them. Horribly. A lesson must be sent out: do not do this.
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
-
Find them. Then kill them. Horribly. A lesson must be sent out: do not do this.
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
-
I was completely flabbergasted by a piece of C# code, until I saw one line near the top (hidden at first in a collapsed block) that read
using var = System.Int32;
Wow, OK. Yes, you can do that, and yes, that makes var (note the colour) behave exactly like int (well like Int32 really - that is, you can't use it as the base type of an enum), and yes, this forum is highlighting it with the wrong colour in the code block.
Whisky Tango Foxtrot?!?
Gryphons Are Awesome! Gryphons Are Awesome!
-
I was completely flabbergasted by a piece of C# code, until I saw one line near the top (hidden at first in a collapsed block) that read
using var = System.Int32;
Wow, OK. Yes, you can do that, and yes, that makes var (note the colour) behave exactly like int (well like Int32 really - that is, you can't use it as the base type of an enum), and yes, this forum is highlighting it with the wrong colour in the code block.
Awesome! Can you some other creating stuff? like. I dunno...
using int = System.String;
?! :P
My programming get away... The Blog... DirectX for WinRT/C# since 2013! Taking over the world since 1371!
-
Awesome! Can you some other creating stuff? like. I dunno...
using int = System.String;
?! :P
My programming get away... The Blog... DirectX for WinRT/C# since 2013! Taking over the world since 1371!
-
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"; // throws an error
String s1 = 5; // this doesn't throw an errorThe quick red ProgramFOX jumps right over the
Lazy<Dog>. My latest article: Understand how bitwise operators work (C# and VB.NET examples) My group: C# Programmers Group -
And this also works:
using System;
...
using String = System.Int32;And:
String s = "str"; // throws an error
String s1 = 5; // this doesn't throw an errorThe quick red ProgramFOX jumps right over the
Lazy<Dog>. My latest article: Understand how bitwise operators work (C# and VB.NET examples) My group: C# Programmers Group -
Find them. Then kill them. Horribly. A lesson must be sent out: do not do this.
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
A bit dramatic, but generally I agree.
Mislim, dakle jeo sam.
-
Find them. Then kill them. Horribly. A lesson must be sent out: do not do this.
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
Precisely my initial reaction. Their head should be mounted on a pike outside the cube farm's walls as a warning to others.
Software Zen:
delete this; -
I was completely flabbergasted by a piece of C# code, until I saw one line near the top (hidden at first in a collapsed block) that read
using var = System.Int32;
Wow, OK. Yes, you can do that, and yes, that makes var (note the colour) behave exactly like int (well like Int32 really - that is, you can't use it as the base type of an enum), and yes, this forum is highlighting it with the wrong colour in the code block.
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.
-
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.
:laugh: 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. :-D
-
I haven't used var except where essential in almost 10 years. :-D
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.
-
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>();
FTFY Just to ensure that nobody use your
dictto 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
-
BobJanova wrote:
var dict = new Dictionary<String, IList<DataColumn>>();
var columnNameDict = new Dictionary>();
FTFY Just to ensure that nobody use your
dictto 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
-
BobJanova wrote:
var dict = new Dictionary<String, IList<DataColumn>>();
var columnNameDict = new Dictionary>();
FTFY Just to ensure that nobody use your
dictto 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
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.
-
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.
