Click here to Skip to main content
Click here to Skip to main content

5 nice things to have in C# 5.0

By , 28 Sep 2010
 

C# 4.0 is out with lots of new specs this year. Few of them are really good, like the support of Task level Parallelism, Dynamic behavior of objects, etc. So C# is very rich now in all respects. But this is not the end of everything. We would love to have new things to come up with C#. So let's discuss a few things which I would love to have.

There is already a buzz around on C# 5.0 specifications in forums. A notable discussion around should be some threads like:

etc. These community links are really great where a lot of people voted for new language specs, while quite a few things are already in process like...

Binding Operators

Binding Operators may be C# 5.0. The support for Binding on .NET objects is awesome. I came to know this from Chris on his post where he speaks how Binding operators looked like long ago. The Delphi assignment operator := is now being used for this purpose. :=: would be used for two way binding. Thus:

comboBox1.Text :=: textBox1.Text; 

means there would be two way binding between the properties so that when ComboBox1.Text changes its Text, it will automatically change the value of Textbox1.Text. Binding is actually not a new thing to the system. In WPF, we already have Binding in place, but for that we need the properties to have implemented from INotifyPropertyChanged. So it is not in the language, the WPF objects are doing this internally by handling the PropertyChanged event on the object. But if that is included as an operator, it would be a cool feature to add on.

Support for Dynamic to the Compiler

Another important candidate for C# 5.0 would be the support for dynamic objects to the compiler itself. There are quite a few occasions where we already did face the flavor of Dynamic behavior of object. You can now defer the determination of type for the object to runtime using the keyword dynamic which is a compile time dynamic while runtime static. The introduction of Expression Trees also defers the compilation of an expression at runtime. You can create objects dynamically at runtime using either inheriting from DynamicObject (which is very easy to do) or by using CodeDom to compile a code at runtime and run the code using reflection. But what if these things are supported by the compiler itself.

As pointed out by Magnus in his post, The future of C# 4.0 and then 5.0, he clearly pointed out what the next version of C# would add up. The compiler must be supporting quite a number of APIs which lets you tweak your code to generate and compile the code at runtime.

But these are not the end of C# 5.0. People all around the globe are putting efforts to make a Wishlist on C# 5.0. A few of those might be:

Pavel's Wishlist on C# 5.0 where he specified quite a number of interesting specs on C# 5.0 but will it be all.

Probably if you ask me what would be your own language features which you like to see, I may name quite a few which I miss:

1. Support for parametrized constructors in Generics.

Yes. it would be nice to have this option in. As we have:

public class T MyClass : T: class, new()

//we might have 
public class T MyClass : T:class, new(int)

This might need adjustment to the compiler. I don't know if it is possible or not. But I definitely miss this in C#.

2. Support for WeakDelegate or WeakEvents

WeakReference, as I have discussed already in my blog or you come across it somewhere else, gives you a tweak to GC. It lets you refer to an object weakly while the GC may still collect it in the process. Thomas, rightly identified that WeakDelegate does not work now. You cannot have WeakDelegate defined in your scope.

3. Better treatment for Null

Working with Null has always been a problem for me. We have to treat nulls separately because there is no type associated with Nulls. With the introduction of Nullables around or Null coalesce operators, still there is scope of improving the Null treatment in the language. Say for instance,

int x? = null;
int y? = x + 40;

which results Y to be null. But don't you think there is a scope of betterment here where the nullables might be treated better in case of working with Operations.

Other than that, we could also have ??? operator in place to treat situations like this:

Myobject obj = null;

Myotherobj obj2 = obj.MyProperty ??? new Myotherobj();

It was introduced by Earlz in his post. Really looks nice, huh.

4. Smart Case support

Yes, Switch - Case could allow expressions. While working with it, I miss it very often. Just like what Charles pointed out, I agree with him totally. I would like to have the option to specify:

switch(myobj)
{
   case string.IsNullorEmpty(myotherobj):
                  .....
   case myotherobj.Trim().Lower:
         ....
}

5. Extension properties

Just as we support extension methods, we could also have extension properties which could probably be used from Extension methods only. It is nice to have in certain cases.

[Associate(string)]
public static int MyExtensionProperty { get;set;}

Something like this might come in very handy at times. Probably some other syntax than Attribute Associate would be more fruitful.

Finally, I would like to see your feedback on the topic. Any other things which you miss? You can point them out to me.

Thanks for reading.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

Abhishek Sur
Team Leader
India India
Member
Did you like his post?
 
Oh, lets go a bit further to know him better.
Visit his Website : www.abhisheksur.com to know more about Abhishek.
 
Abhishek also authored a book on .NET 4.5 Features and recommends you to read it, you will learn a lot from it.
http://bit.ly/EXPERTCookBook
 
Basically he is from India, who loves to explore the .NET world. He loves to code and in his leisure you always find him talking about technical stuffs.
 
Presently he is working in WPF, a new foundation to UI development, but mostly he likes to work on architecture and business classes. ASP.NET is one of his strength as well.
Have any problem? Write to him in his Forum.
 
You can also mail him directly to abhi2434@yahoo.com
 
Want a Coder like him for your project?
Drop him a mail to contact@abhisheksur.com
 
Visit His Blog

Dotnet Tricks and Tips



Dont forget to vote or share your comments about his Writing

Sign Up to vote   Poor Excellent
Add a reason or comment to your vote: x
Votes of 3 or less require a comment

Comments and Discussions

 
You must Sign In to use this message board.
Search this forum  
    Spacing  Noise  Layout  Per page   
GeneralMy vote of 5memberTamil Selvan K19 Jul '12 - 22:15 
C# Rocks!!
GeneralMy vote of 3 [modified]memberjfriedman11 Sep '11 - 8:14 
Extension Operators and Properties?

modified 18 Nov '11 - 16:52.

GeneralOther proposalmemberStéphane Issartel13 Oct '10 - 5:56 
I do a lot of math and its quite boring and obfuscating to repeat all the time Math.Cos, Math.Log, Math.Blabla ... May be nice to allow not repeating for class name when things are 100% non ambiguous (or add some '#implicit Math' directive to really state "Dear compiler, yes I know I did not put useless 'Math.' in front of my static methods, please don't be silly and only warn me when things get ambiguous for you").
 
e.g.: var y = u * Math.Cos(v); ==> var y = u * Cos(v);
 
NB: Currently for short algorithms I don't mind so much to put 'Math.' everywhere, for longer ones I prefer to add a bunch of static methods like 'private static double cos(double x) { return Math.Cos(x); }'
GeneralRe: Other proposalmvpAbhishek Sur18 Oct '10 - 10:33 
I think you wanted for With of VB.... Smile | :)
Abhishek Sur
Don't forget to click "Good Answer" if you like this Solution.
Visit My Website-->


www.abhisheksur.com

GeneralNone of the abovememberWebBiscuit8 Oct '10 - 22:58 
I don't want to see any of these features. I don't want C# to become an evil playground for obscure fancy operators. One of the biggest problems we are going to have with the future of C# is that it's not controlled by any standard committee. It is Microsoft's toy, and although they are doing a fine job right now, they may become carried away.
GeneralA Modest ProposalmemberLee Robie5 Oct '10 - 15:51 
Several of these would be useful to me, but I would prefer to have none. As you add more features, the combinatorial complexity gets worse and worse. I like C# but I fear it is already so complex that I can't possibly understand all of it, especially the interactions.
 
Each new feature has value for certain cases, but there is a cost: increasing, crushing complexity (like what happened to C++). Less is more, and enough is enough.
- lee r.

GeneralMy vote of 5memberAnurag Gandhi5 Oct '10 - 6:57 
Nice Article. Thanks for the Info. Smile | :)
GeneralInteresting ideas!memberKubajzz29 Sep '10 - 2:46 
I really like your first idea: support of parametric constructrs in generic constraints. I agree that it would be a very useful feature.
 
As for the other ideas, many of them are interesting, but most of them are pure nonsenses IMO...
 
For example allowing expressions in switch statements would bring one big problem - more than one case statement could be valid, which would result in ambiguous execution.
 
"Better treatment for Null" sounds good... Null values do sometimes bring problems and you have to write a lot of code to check for nulls, but at least the system is simple and consistent. Changing it would bring more damage than help.

As for extension properties, the only problem is that you need some place to store the actual data. Extension methods are in fact static, so adding an extension method to a class doesn't change the original class. However, adding an extension property would require some additional memory space to be allocated... which is not easy.
 
So, to sum this up, I'm glad people like you are not the designers of C#. None the less, it was a pleasure to read this article and I thank you for the interesting ideas.
GeneralRe: Interesting ideas!mvpAbhishek Sur29 Sep '10 - 11:53 
Kubajzz wrote:
but most of them are pure nonsenses IMO...

 
I guess not... Big Grin | :-D Big Grin | :-D
 

Kubajzz wrote:
allowing expressions in switch statements would bring one big problem

 
Then what the programmers are for? Compiler alternatives are good, complexity should be avoided from the programmers point of view. Fact is I thought it is not necessary to have compiler constants for Case statements.
 

Kubajzz wrote:
"Better treatment for Null" sounds good...

 
I am talking about Nullables<T> where T : struct not null itself. Wink | ;) Wink | ;)
 

Kubajzz wrote:
As for extension properties, the only problem is that you need some place to store the actual data.

 
I have designed my extension method as static as well. May be a static implementation of a class with both extension method and extension property can stay. For extension methods we need to add a namespace, so there is no ambiguity I guess.
 

Kubajzz wrote:
So, to sum this up, I'm glad people like you are not the designers of C#.

 
Shucks | :-> Shucks | :->
Abhishek Sur
Don't forget to click "Good Answer" if you like this Solution.
Visit My Website-->


www.abhisheksur.com

GeneralRe: Interesting ideas!memberKubajzz30 Sep '10 - 8:45 
Thanks for your answer. I need some more clarification though.
 
Abhishek Sur wrote:
Kubajzz wrote:
allowing expressions in switch statements would bring one big problem
 
Then what the programmers are for? Compiler alternatives are good, complexity should be avoided from the programmers point of view. Fact is I thought it is not necessary to have compiler constants for Case statements.

 
Ok, I must be missing something here... Let's try again. There must always be at most 1 matching case statement for the given expression to avoid ambigous control flow and compiler has to enforce this rule. I'm sure you agree with this.
 
Now please explain me one thing: if expressions are allowed in case statements, can the compiler guarantee that no more than 1 case statement is valid at all times? I say no.
 

As for those extension properties, I guess I didn't exlpain my question well enough... I know the property is declared as static just like an extension method, but it is supposed to extend instances of a types just like extension methods do, right? Therefore the property would behave like an instance property although it is declared static (that's exactly what extension methods do).
 
If the property behaves like an instance property, it has to store instance data. There would have to be additional memory allocated for every instance of that type to store the data. Where will the data be stored? That's what I was asking about...
 

One rant in the end... Is that a new habit that every comment other than "Awesome!" and "Great article, thanks!" gets the vote of 1? I don't say the voter was you (I believe every reasonable author appreciates constructive criticism), I'm just saying it's strange...

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Permalink | Advertise | Privacy | Mobile
Web03 | 2.6.130523.1 | Last Updated 29 Sep 2010
Article Copyright 2010 by Abhishek Sur
Everything else Copyright © CodeProject, 1999-2013
Terms of Use
Layout: fixed | fluid