C Sharps - how are you getting on with nullable reference types?
-
I'm having one of those mornings where I try and catch up on new features they've stuck in C# and .NET. I have to say I don't always like what I read, maybe I'm a coding language Conservative or something, but I do sometimes come around to new features about five years late. Nullable reference types (they're nullable already surely?) ([Embracing nullable reference types | .NET Blog](https://devblogs.microsoft.com/dotnet/embracing-nullable-reference-types/)) is one such example that when I first heard about it a year or two ago I thought it so preposterous that I would never activate it, and sure enough there are no ?s at the end of my strings to date. Now do I dig in or accept change? A null reference, well a null pointer, ultimately a bad address in memory just seems to me an inherent trap with computers. I first did it 40 years ago on a Commodore VIC20 before they had invented exceptions, the thing would just go mental until you switched it off. And every day since for that matter but usually by production such errors are gone. In development they're a good pointer (hey, a pun!) to where things aren't quite right yet. I like things the way they are (were). How do you like nullable reference types?
Regards, Rob Philpott.
I tried them first in swift where they are called more appropriately (at least to me) Optionals They basically have the same syntax and behavior and they are neat! (unless you force unwrap a null value and everything explodes as a normal null usage would do)
-
I'm having one of those mornings where I try and catch up on new features they've stuck in C# and .NET. I have to say I don't always like what I read, maybe I'm a coding language Conservative or something, but I do sometimes come around to new features about five years late. Nullable reference types (they're nullable already surely?) ([Embracing nullable reference types | .NET Blog](https://devblogs.microsoft.com/dotnet/embracing-nullable-reference-types/)) is one such example that when I first heard about it a year or two ago I thought it so preposterous that I would never activate it, and sure enough there are no ?s at the end of my strings to date. Now do I dig in or accept change? A null reference, well a null pointer, ultimately a bad address in memory just seems to me an inherent trap with computers. I first did it 40 years ago on a Commodore VIC20 before they had invented exceptions, the thing would just go mental until you switched it off. And every day since for that matter but usually by production such errors are gone. In development they're a good pointer (hey, a pun!) to where things aren't quite right yet. I like things the way they are (were). How do you like nullable reference types?
Regards, Rob Philpott.
The way I see it, if you've turned on NRT, haven't got any strings with ? at the end, and no compiler errors, you're doing well :-) I use NRT all the time, since it was in the prototype stages, and I love it. The ability for the compiler to warn when you're accidentally using something that is potentially null is really useful. Especially things that you didn't previously realise could return null!
-
The way I see it, if you've turned on NRT, haven't got any strings with ? at the end, and no compiler errors, you're doing well :-) I use NRT all the time, since it was in the prototype stages, and I love it. The ability for the compiler to warn when you're accidentally using something that is potentially null is really useful. Especially things that you didn't previously realise could return null!
How does this work? So a string in the normal way can be null, but with nrt turned on will not accept null. This creates an ambiguity, so a string in something like an interface - a strict definition of properties and methods etc. can suddenly become ambiguous depending on the nrt context. I'm struggling to see how this works in the framework and libraries. Well worn methods that have been around decades which return string but should now return string?. It's almost like you'd need two frameworks, one enabled for NRT and one not. I don't get it. But I have decided to turn it on, and it'll all probably make sense soon.
Regards, Rob Philpott.
-
How does this work? So a string in the normal way can be null, but with nrt turned on will not accept null. This creates an ambiguity, so a string in something like an interface - a strict definition of properties and methods etc. can suddenly become ambiguous depending on the nrt context. I'm struggling to see how this works in the framework and libraries. Well worn methods that have been around decades which return string but should now return string?. It's almost like you'd need two frameworks, one enabled for NRT and one not. I don't get it. But I have decided to turn it on, and it'll all probably make sense soon.
Regards, Rob Philpott.
Bear in mind that this is a compiler-only thing - once compiled, all strings are back to being normally nullable. If you have function declaration: `void M(string s) { }`, the idea is that you can be assured that `s` is going to be a not-null string. Because, where you call that function, you will be warned if you try `M(null)`, or ``` string? s; M(s); ``` The only times you are expected to test for null are: 1) If you receive a string? from a function. You should check for non-null before you use it. 2) Even if you have a not-null string parameter, if that method is external facing, another project may still send a null string (obviously this all works for any reference type, not just strings...) Does that help?
-
Bear in mind that this is a compiler-only thing - once compiled, all strings are back to being normally nullable. If you have function declaration: `void M(string s) { }`, the idea is that you can be assured that `s` is going to be a not-null string. Because, where you call that function, you will be warned if you try `M(null)`, or ``` string? s; M(s); ``` The only times you are expected to test for null are: 1) If you receive a string? from a function. You should check for non-null before you use it. 2) Even if you have a not-null string parameter, if that method is external facing, another project may still send a null string (obviously this all works for any reference type, not just strings...) Does that help?
It does - thank you. I think I should perhaps be figuring this out for myself rather than burdening others mind! Code below shows my confusion, a simple thing to write a text file to the console. Now I turn NRT on, my 'line' variable should now become type 'string?', but ReadLine() doesn't start suddenly returning 'string?', surely it maintains it's 'string' return type. There is a (perceived by me) mismatch between my NRT code and the non-NRT framework.
public void Test()
{
using (StreamReader s = new StreamReader(@"c:\myfile.txt"))
{
string line = s.ReadLine();while (line != null) { Console.WriteLine(line); line = s.ReadLine(); } }}
You know what, I think I'll try it right now...
Regards, Rob Philpott.
-
It does - thank you. I think I should perhaps be figuring this out for myself rather than burdening others mind! Code below shows my confusion, a simple thing to write a text file to the console. Now I turn NRT on, my 'line' variable should now become type 'string?', but ReadLine() doesn't start suddenly returning 'string?', surely it maintains it's 'string' return type. There is a (perceived by me) mismatch between my NRT code and the non-NRT framework.
public void Test()
{
using (StreamReader s = new StreamReader(@"c:\myfile.txt"))
{
string line = s.ReadLine();while (line != null) { Console.WriteLine(line); line = s.ReadLine(); } }}
You know what, I think I'll try it right now...
Regards, Rob Philpott.
It depends on which version of C# you're using. In NET5 (or maybe even Core3.1), StreamReader#ReadLine does return string?. All of the core library is now annotated with ? and attributes which assist the NRT parser. You'll find this a lot in reflection and other methods which used to potentially return null.
-
It depends on which version of C# you're using. In NET5 (or maybe even Core3.1), StreamReader#ReadLine does return string?. All of the core library is now annotated with ? and attributes which assist the NRT parser. You'll find this a lot in reflection and other methods which used to potentially return null.
Yes I did just try my example, under .NET5 as it happens and the return type magically changed. I just find it a bit strange that turning on nullable here, makes something nullable over there. I notice also that 'HasValue' and 'Value' are missing to keep it in line with value types but I guess this is because its a compiler thing not a framework thing as you say.. Thanks for your help.
Regards, Rob Philpott.
-
Yes I did just try my example, under .NET5 as it happens and the return type magically changed. I just find it a bit strange that turning on nullable here, makes something nullable over there. I notice also that 'HasValue' and 'Value' are missing to keep it in line with value types but I guess this is because its a compiler thing not a framework thing as you say.. Thanks for your help.
Regards, Rob Philpott.
Yeah, the Value and HasValue properties are possible for nullable value types, because they are implemented by wrapping the value type in a `Nullable`. Nullable reference types is just a compiler warning wave telling you when a reference type is null and shouldn't be, etc. The thing to remember is that StreamReader#ReadLine could always return null. The difference is that it now makes it clear by telling you "I return string?", as opposed to returning string and you not realising.
-
I'm having one of those mornings where I try and catch up on new features they've stuck in C# and .NET. I have to say I don't always like what I read, maybe I'm a coding language Conservative or something, but I do sometimes come around to new features about five years late. Nullable reference types (they're nullable already surely?) ([Embracing nullable reference types | .NET Blog](https://devblogs.microsoft.com/dotnet/embracing-nullable-reference-types/)) is one such example that when I first heard about it a year or two ago I thought it so preposterous that I would never activate it, and sure enough there are no ?s at the end of my strings to date. Now do I dig in or accept change? A null reference, well a null pointer, ultimately a bad address in memory just seems to me an inherent trap with computers. I first did it 40 years ago on a Commodore VIC20 before they had invented exceptions, the thing would just go mental until you switched it off. And every day since for that matter but usually by production such errors are gone. In development they're a good pointer (hey, a pun!) to where things aren't quite right yet. I like things the way they are (were). How do you like nullable reference types?
Regards, Rob Philpott.
NRE is pathetic try of MS to eliminate tons of idiotic mistakes made by indian monkeys coders. PROBLEM is this cure more annoys normal developers, than helps 'em. NRE is one of stupid "improvements" by MS. Pity, but MS lost all professional developers and now current MS IQ is below 100.
-
I'm having one of those mornings where I try and catch up on new features they've stuck in C# and .NET. I have to say I don't always like what I read, maybe I'm a coding language Conservative or something, but I do sometimes come around to new features about five years late. Nullable reference types (they're nullable already surely?) ([Embracing nullable reference types | .NET Blog](https://devblogs.microsoft.com/dotnet/embracing-nullable-reference-types/)) is one such example that when I first heard about it a year or two ago I thought it so preposterous that I would never activate it, and sure enough there are no ?s at the end of my strings to date. Now do I dig in or accept change? A null reference, well a null pointer, ultimately a bad address in memory just seems to me an inherent trap with computers. I first did it 40 years ago on a Commodore VIC20 before they had invented exceptions, the thing would just go mental until you switched it off. And every day since for that matter but usually by production such errors are gone. In development they're a good pointer (hey, a pun!) to where things aren't quite right yet. I like things the way they are (were). How do you like nullable reference types?
Regards, Rob Philpott.
-
I'm having one of those mornings where I try and catch up on new features they've stuck in C# and .NET. I have to say I don't always like what I read, maybe I'm a coding language Conservative or something, but I do sometimes come around to new features about five years late. Nullable reference types (they're nullable already surely?) ([Embracing nullable reference types | .NET Blog](https://devblogs.microsoft.com/dotnet/embracing-nullable-reference-types/)) is one such example that when I first heard about it a year or two ago I thought it so preposterous that I would never activate it, and sure enough there are no ?s at the end of my strings to date. Now do I dig in or accept change? A null reference, well a null pointer, ultimately a bad address in memory just seems to me an inherent trap with computers. I first did it 40 years ago on a Commodore VIC20 before they had invented exceptions, the thing would just go mental until you switched it off. And every day since for that matter but usually by production such errors are gone. In development they're a good pointer (hey, a pun!) to where things aren't quite right yet. I like things the way they are (were). How do you like nullable reference types?
Regards, Rob Philpott.
I have read about nullable types, including reference types. However, I have yet to find a use for them. I tend to write code as simple as I can so I find a lot of these new features seem to just offer me new ways of writing more complicated code.
-
I'm having one of those mornings where I try and catch up on new features they've stuck in C# and .NET. I have to say I don't always like what I read, maybe I'm a coding language Conservative or something, but I do sometimes come around to new features about five years late. Nullable reference types (they're nullable already surely?) ([Embracing nullable reference types | .NET Blog](https://devblogs.microsoft.com/dotnet/embracing-nullable-reference-types/)) is one such example that when I first heard about it a year or two ago I thought it so preposterous that I would never activate it, and sure enough there are no ?s at the end of my strings to date. Now do I dig in or accept change? A null reference, well a null pointer, ultimately a bad address in memory just seems to me an inherent trap with computers. I first did it 40 years ago on a Commodore VIC20 before they had invented exceptions, the thing would just go mental until you switched it off. And every day since for that matter but usually by production such errors are gone. In development they're a good pointer (hey, a pun!) to where things aren't quite right yet. I like things the way they are (were). How do you like nullable reference types?
Regards, Rob Philpott.
"they're nullable already surely?" The point is by opting into nullables it makes them NON-nullable by default, rather than nullable by default. I've dived in with both non-nullable reference types and C# 9 records in a greenfield project. A few sprints in and I'm really pleased with how it's influenced / affected the codebase. Records are wonderful for letting details stand out in simple classes, and their immutability drives your design down a positive path. Similarly with the non-nullable reference types, it can be a little jarring at first, but it pretty much just means the compiler can infer more than it could before, and points you to more issues. Sometimes they're "non-issues", that wouldn't really have mattered, but there have definitely been a couple of points where it's caused me to think something deeper that may have been an issue. Null has its uses, and you're not stopped from using it. By introducing Nullable Reference Types into your codebase you're not avoiding the use of null, you're just making it absolutely clear when something can and when something can't be null. And in my opinion that's strong a positive.