In the few next posts I’d like to share with you some of the most interesting C# 8.0 features. Today we’re going to start with examining nullable reference types. Let’s see then 🙂
Learn about building C# 8.0
C# 8.0 is going to be the next major release of C# language. It should be released by the same time as .NET Core 3.0.
What I find very interesting is C# language GitHub repository. Among others, you can find there very interesting notes from C# language design meetings 🙂 If you filter well, you can also list so called “proposals”, which are current candidates for new C#’s version (or sub-versions) features. By clicking here you can list C# 8.0 candidates.
I will publish a separate post regarding each feature which I find particularly interesting 🙂
Nullable reference types
First of the C# 8.0 features I’d like to discuss are nullable reference types. It seems it’s going to change the way we write our code, so it’s worth knowing this feature.
A bit of history – NullReferenceException
Consider the following code:
Guess what happens after executing this as a console app? Of course, our favorite NullReferenceException is thrown:
In this case, jsDev.LastName is of course set to null.
NullReferenceException has been a nightmare for thousands of developers (and users) for many years. What if, in the cases like our example, we knew before that in this place our object might be null?
New world – #nullable enable
For that purpose, C# development team is introducing nullable reference types. In essence, it makes reference types (like string) non-nullable! However to not be a tough nut to crack, all issues related to assigning null value to non-nullable reference types are presented as warnings, not errors.
In order to use this feature, you need to enable it. You can do it with a preprocessor directive #nullable enabled. We can do it directly in the source code file. In the future, it should also be possible to enable it on project level.
Notice what happens when we enable it in our example:
We’re still able to compile, but this nice warning is displayed 🙂 As soon as we initialize LastName property in the constructor, the warning disappears:
If you try to cheat, it still works like a charm 🙂 :
But hey… what if you actually want null in this particular string? You need to explicitly mark your reference type variable as nullable. You probably recall nullable value types like int?, don’t you (read this post if you don’t remember the difference between value and reference types)? Now you can do the same with non-nullable reference types:
Nonetheless, in such case, the compiler still takes care of us:
The final fix is quite obvious – we need to check for null first:
At this stage all warnings finally disappear. You can find the finished source code here.
Nullable reference types in IL
The only thing I found in the IL code compiled from source code with #nullable enabled directive was NullableAttribute applied to properties:
It seems that nullable reference types are implemented by applying this attribute to variables, which is only used by the compiler (runtime is not affected).
Summary
I’m really excited about nullable reference types in C# 8. I personally feel that it even introduces some clarity in the language – we’ll have explicit declarations for nullable value and reference types. However, in more complex scenarios it may bring some confusion in regards to reference types and using “?” character (like generics or collections – see Jon Skeet’s post for more details). For sure it’s a significant step towards eliminating issues with exceptions caused by null references.
What do you think about nullable reference types? Is it a good direction in which C# language is going? Share your thoughts in the comments! 😉
