C# language is getting a lot of new features. Some interesting mentions are private protected, or default implementation in interfaces, etc. In fact, one of the advantage of using C# and .NET is the large feature-set that is available for you. And of course, you have choice to use only those features which are really needed by your application.
In this article we are going to talk about static abstract members. Static abstract members have been there for a while. They were introduced with .NET 6, but they were marked as preview feature. In this article, I will try to compile some practical information about this feature.
Prior to .NET 6
Prior to .NET 6, marking a static member as virtual or abstract was illegal. Meaning, if you mark a static member as abstract or virtual was raising a compiler error – similar to what is shown below.
The below code was written in a console application which is targeting .NET 6 and C# 10. But because preview features are not enabled, I am getting the compile time error suggesting that the syntax is invalid. The error is suggesting to either enable the preview features.
If your project is not targeting .NET 6 and it is targeting to older versions of .NET, then you will get compiler error cs0112.
So the bottom-line is – till .NET 6, static abstract members were not allowed in the interfaces.
When was static abstract members introduced ?
So, as mentioned earlier, this feature was introduced with .NET 6, but it was in preview state. If you want to enable this feature, then you will have to set language version to preview.
With C# 11 and .NET 7, this feature is now going to become generally available. It means, if the project is targeting to .NET 7 and C# 11, this feature will be enabled by default.
What is the new behavior ?
Almost all of us know that static abstract methods were not allowed. What is the new behavior ?
Of course the new behavior is – you will not get any error if you define a static abstract member. So, if I create a new console application which is targeting to .NET 7 and then add the same interface which is shown in the snapshot above, it would not cause a compilation error.
Where this feature can prove handy ?
This feature can be handy when it comes to dealing with generics. If a method has a generic type parameter, and that method needs to call a static method from that generic type parameter, there was no easy way for this.
One option was either to use type casting or the other option was to declare the method as member method.
This new feature would come handy in such scenarios. We can include the static abstract members in the interfaces and then we can specify a constraint on generic method that type parameter should be derived from this specific interface. Once this is done, the generic method can then easily call the static method.
Demo – Generic Math Operation
Now, let’s have a look at an example to understand what I mentioned in the previous section.
Consider there is an interface ISport, which has a static abstract member – IsTeamSport, to identify if a team is needed to play the sport. Then there are 4 different implementations of that interface:
Football,Cricketwhich are team sportsBowling,Swimmingwhich can be played by individual without strictly needing a team
The code snippet is given below.
Now, let’s write a simple Display method, which is a generic method and it takes a type parameter. This type parameter has a constraint, and as per that constraint, the type must be derived from the interface – ISport.
The method definition is shown in the code snippet given below.
Without static abstract member in the ISport, it would not have been possible to call the static method without type casting or without using reflection. But as you can see in above snippet, calling static method is very easy as compared to it was before.
Wrapping up
I hope this article has helped you to know more about this feature. Have you already used this feature already ? Are you planning to use this feature in near future ? Let me know your thoughts.
