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.
One of the few features I was really looking forward to. And I am happy with it. Null is very often a special case - and now I can clearly express in the code if this special case is something that needs to be delt with, or something that will not happen. Meaning guard code is in added where it is needed, and not filling up the code where doesn't do anything. Why you would not want the compiler to help identifying inherit traps is something I just don't understand. Maybe because I never had to struggle with assembly on the VIC20 - I was one of those modern kids that did assembly on the C64. :)
-
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.
Coming from a C++ background, I would say that the whole point of references (as opposed to pointers) is that a reference can never be null; nullable references are a fundamental violation of the programming model. If you want pointers, why not use C++?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
One of the few features I was really looking forward to. And I am happy with it. Null is very often a special case - and now I can clearly express in the code if this special case is something that needs to be delt with, or something that will not happen. Meaning guard code is in added where it is needed, and not filling up the code where doesn't do anything. Why you would not want the compiler to help identifying inherit traps is something I just don't understand. Maybe because I never had to struggle with assembly on the VIC20 - I was one of those modern kids that did assembly on the C64. :)
lmoelleb wrote:
Why you would not want the compiler to help identifying inherit traps is something I just don't understand.
That's a strong argument. Compile time errors have to beat runtime. But I guess I'm just very relaxed about things being null. It's a useful paradigm for 'there isn't one' etc. Reading from a StreamReader for instance gives you a null at the end of the stream, perfect condition on the loop. But then I guess the argument is that it should be a
string?How are they going to do away with the divide by zeros? That's what I want to know!Regards, Rob Philpott.
-
Coming from a C++ background, I would say that the whole point of references (as opposed to pointers) is that a reference can never be null; nullable references are a fundamental violation of the programming model. If you want pointers, why not use C++?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Daniel Pfeffer wrote:
If you want pointers, why not use C++?
Because of header files, and 20 years of .NET has made me too stupid in general.
Regards, Rob Philpott.
-
Daniel Pfeffer wrote:
If you want pointers, why not use C++?
Because of header files, and 20 years of .NET has made me too stupid in general.
Regards, Rob Philpott.
To be aware of it is the first step :laugh: :laugh: :laugh:
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Yes it seems var, Brexit and Covid lockdowns are the divisive issues of our times. I'd venture that the young probably are more advocates of var, particularly if they've come from some horrible dynamic language. But those of us who went through the OO revolution in the 90s and had the 'type is everything' mantra drummed into us just find it obscures things. I don't mind dynamic, but there has to be a very good reason for it!
Regards, Rob Philpott.
varand dynamic languages have nothing in common. If anything,varis coming from functional languages with stronger type safety than C# and which won'tletyou do it any other way :) -
lmoelleb wrote:
Why you would not want the compiler to help identifying inherit traps is something I just don't understand.
That's a strong argument. Compile time errors have to beat runtime. But I guess I'm just very relaxed about things being null. It's a useful paradigm for 'there isn't one' etc. Reading from a StreamReader for instance gives you a null at the end of the stream, perfect condition on the loop. But then I guess the argument is that it should be a
string?How are they going to do away with the divide by zeros? That's what I want to know!Regards, Rob Philpott.
No one is arguing against null being a useful paradigm. And now we have the syntax to tell if the paradigm is used or not. This serves two purposes: 1) Communicate intent. You can see from the type of my method if you need to handle a null being returned. You can see by the parameter definition if my code can handle a null being passed in. 2) Compiler can catch more mistakes. Either of these would be more than enough for me to use nullable - with both of these... don't get why you would not use it on any new code. Legacy code is of course always an issue... when to (and if) make the investment to change it.
-
Coming from a C++ background, I would say that the whole point of references (as opposed to pointers) is that a reference can never be null; nullable references are a fundamental violation of the programming model. If you want pointers, why not use C++?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
Daniel Pfeffer wrote:
a reference can never be null
They're not supposed to be null, but they can be. If someone passes
*ptras an argument, andptrisnullptr, defensive code still has to includeif(&ref == nullptr).Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
No one is arguing against null being a useful paradigm. And now we have the syntax to tell if the paradigm is used or not. This serves two purposes: 1) Communicate intent. You can see from the type of my method if you need to handle a null being returned. You can see by the parameter definition if my code can handle a null being passed in. 2) Compiler can catch more mistakes. Either of these would be more than enough for me to use nullable - with both of these... don't get why you would not use it on any new code. Legacy code is of course always an issue... when to (and if) make the investment to change it.
I have to say your starting to convince me, this is hard to argue with. I think I might try it out later on and see how it feels..
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.
Pointless. Used by inferior practitioners.
-
Pointless. Used by inferior practitioners.
-
That's a difficult one. I haven't started using them, but I suspect I probably should on the basis that the more errors I can catch at compile time rather than run time means less errors I have to specifically test for or code to handle. I can't help the feeling that there are too many C++ and VB fanboise trying to get the nastier bits of of their original code into the C# spec though:
varwithout Linq,dynamic, and so on does kinda dumb down the language without adding any benefit in the real world."I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
I don't think
vardumbs down the language any more thanautodumbs down C++. You may not like it, but it saves *typing* not *thinking*, IMO. Besides, in C# due to lack of a reasonable alternative to typedef it's par for the course, LINQ or no - if you're using a lot of generics.Real programmers use butterflies
-
Daniel Pfeffer wrote:
If you want pointers, why not use C++?
Because of header files, and 20 years of .NET has made me too stupid in general.
Regards, Rob Philpott.
I recently came back home to C++ from years long C# development. I'm a bit rusty, but it's coming back. You may surprise yourself if you give it another go. *hides*
Real programmers use butterflies
-
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 suspect enabling this will wreak havoc on all the entity models with string properties where the backing field in the DB is nullable. ;)
Latest Articles:
Thread Safe Quantized Temporal Frame Ring Buffer -
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.
Sounds like a great addition to me. And if I have understood it correctly there is no actual addition of nullable reference types. What you get is an option where the compiler looks for possible null reference errors. So when null references are EXPECTED you need to mark those fields as nullable to not get a warning.
Wrong is evil and must be defeated. - Jeff Ello Never stop dreaming - Freddie Kruger
-
I suspect enabling this will wreak havoc on all the entity models with string properties where the backing field in the DB is nullable. ;)
Latest Articles:
Thread Safe Quantized Temporal Frame Ring BufferThat's probably one of the reasons it's an option and not default. Entity framework will of course be updated to support it though.
Wrong is evil and must be defeated. - Jeff Ello Never stop dreaming - Freddie Kruger
-
Daniel Pfeffer wrote:
a reference can never be null
They're not supposed to be null, but they can be. If someone passes
*ptras an argument, andptrisnullptr, defensive code still has to includeif(&ref == nullptr).Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.Dereferencing a nullptr is already undefined behaviour. You have already "broken the machine" before making the call, so anything that happens now - including termination of the program - is possible. Because the machine is broken, defensive programming is the wrong answer. You should use methods outside the C++ model (e.g. Windows Structured Exception Handling) in order to restart the program from a known OK point, or abort gracefully with an intelligible message to the user.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
Dereferencing a nullptr is already undefined behaviour. You have already "broken the machine" before making the call, so anything that happens now - including termination of the program - is possible. Because the machine is broken, defensive programming is the wrong answer. You should use methods outside the C++ model (e.g. Windows Structured Exception Handling) in order to restart the program from a known OK point, or abort gracefully with an intelligible message to the user.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
It's not undefined behavior yet. Almost every compiler just passes the unchecked
nullptrreference to the called function, which goes off the cliff if it uses the member selection operator. The called function can therefore protect itself in the way described, and fail gracefully if it wishes.Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
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 didn't / don't get it either. If all your function does is return an object, what do you do when there's a problem? I return null instead of throwing an exception (which seems to be the knee-jerk response). New LINQ queries? We have FirstOrNull(), LastOrNull(). Will it now be FirstOrNullOrNotNull()?
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
Coming from a C++ background, I would say that the whole point of references (as opposed to pointers) is that a reference can never be null; nullable references are a fundamental violation of the programming model. If you want pointers, why not use C++?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
When is a reference not a pointer? What comes first? The variable, the reference or the pointer?
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
