5 things I would like to see in C# 5.0

C# 4.0 is out with a 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 respect. But this is not the end of everything. As I did introduced few old but Unknown C# topics, I would also love to explore new things that comes up with C#. So lets 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

What features you want to see in C# 5.0
C# language speculation 4.5 /5.0

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

Binding Operators

Binding Operators may be C# 5.0. The support for Binding on .net objects are awesome. I came to know this from Chris on his post where he speaks how Binding operators looks like long ago. The delphi assignment operator := is now been used in 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 occasion where we already did faced the flavor of Dynamic behavour of object. You can now defer the type 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 which 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 to 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. Peoples 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 the 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 dont 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 with it somewhere else, gives you a tweak to GC. It lets you to refer 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 a problem to 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 dont 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 him totally. I would like to have the option to specify

   case string.IsNullorEmpty(myotherobj):
   case myotherobj.Trim().Lower:

5. Extension properties

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

public static int MyExtensionProperty { get;set;}

Something like this might come 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 it to me.

Thanks for reading.
Shout it Submit this story to DotNetKicks Bookmark and Share
Read Disclaimer Notice


Hüseyin Cevizci said...

Good suggestions. Especially "null" issue is the most urgent topic, in my opinion. There are some other posts for this need I read on the internet. I think in C# 5.0, there will be improvements for that.

Abhishek Sur said...


Yes, there is an issue with Nullables on Arithmetic operations. Probably it is a nice to have option for us.

Anonymous said...

Are you serious?

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

//we might have

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

^ does this honestly look readable or comprehensible to people?!

Abhishek Sur said...


Why not, when new() can make sense why not new(int), new(object) does not make sense.

My idea was not to make emphasis on syntax or how it looks like, my idea is to support the feature.

As <out T> in place with 4.0 this will restrict the object to have strict parameterized constructor for type T.

Paul C Smith said...

Injectable serialization contracts, possibly by overridable member attributes (DataMember, XmlAttribute, Serializable). Whose idea was the declarative approach that couples serialization control with member definitions?

Under the current paradigm, having multiple situation-based serialization behaviors requires you to do something clunky, e.g. write a duplicate DTO with different serialization attributes.

ILGenerator.Emit can create almost any custom method you could need for serialization... instancing for classes with no zero-argument constructor, getting & setting of private member values, and so on. Why not facilitate contracts as imperatively created sets of instancing, read and write specifications, decoupled from the source and target class definitions?

This would have the side-benefit of making deep-cloning of reference types much easier.

Abhishek Sur said...


Thanks for your suggestions. Yes ILGenerator.Emit can generate any new Type at runtime. But the notion of my post is need for more flexible support for the existing features.

Serializability is an issue if there is no default constructor for the type. So new(arg) would not worth if Serialization is taken into consideration. I agree with you. Also deep - cloning for types would create bottlenecks if there are large number of types with no default constructors.

I appreciate your thoughts and glad you read my post.

Pallab Dutta said...

Most of people think about what they are working on and evaluate on present feature of the programming language..
Most of time they never bother to think about the loophole and missing part of the language..
I really appreciate the way you think…
I think it will really help us to build a better platform..

Abhishek Sur said...


Thank you Pallab, and I am glad you liked my post.

Unknown said...

I really vote for that switch :) amazing :)

ppy said...

I really want to see compile-time #includes (mainly for huge blocks of using statements / #if conditions that are common to all source files).

Highly agree on the switch/case one.

Rhyous said...

I would like XML Serialization to not crash when serializing a child object.

class a1
public String name {get; set;}

class b2 : a1
// code here

List list = new List();
list.add(new b2());

Why should I have to tell a1 about b2 in order to serialize it as if it were a1?

Rashmi Agarwal said...

I would also like to see the following two things in C# 5.0
1.) Auto Implementation of INotify in auto properties.

2) Dynamically adding pre/ post functions to property/ method.

Post a Comment

Please make sure that the question you ask is somehow related to the post you choose. Otherwise you post your general question in Forum section.

Author's new book

Abhishek authored one of the best selling book of .NET. It covers ASP.NET, WPF, Windows 8, Threading, Memory Management, Internals, Visual Studio, HTML5, JQuery and many more...
Grab it now !!!