C Sharps - how are you getting on with nullable reference types?
-
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
-
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.Greg Utas wrote:
It's not undefined behavior yet.
It is: A reference shall be initialized to refer to a valid object or function. [Note: in particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the “object” obtained by dereferencing a null pointer, which causes undefined behavior. As described in 9.6, a reference cannot be bound directly to a bit-field.] Just because it works today on your set of compilers, does not mean it will continue to work tomorrow when for instance standard introduce contracts or compiler implementer decide to make optimizations based on the assumption. Compilers are already taking UB as license to do optimizations, giving language users all kind of WTF moments. Most famous case of a similar nature is probably this one in Linux: [Fun with NULL pointers, part 1 [LWN.net]](https://lwn.net/Articles/342330/) The point is you cannot reason about UB.
-
Greg Utas wrote:
It's not undefined behavior yet.
It is: A reference shall be initialized to refer to a valid object or function. [Note: in particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the “object” obtained by dereferencing a null pointer, which causes undefined behavior. As described in 9.6, a reference cannot be bound directly to a bit-field.] Just because it works today on your set of compilers, does not mean it will continue to work tomorrow when for instance standard introduce contracts or compiler implementer decide to make optimizations based on the assumption. Compilers are already taking UB as license to do optimizations, giving language users all kind of WTF moments. Most famous case of a similar nature is probably this one in Linux: [Fun with NULL pointers, part 1 [LWN.net]](https://lwn.net/Articles/342330/) The point is you cannot reason about UB.
I agree that the naughty code should be trapped, but most compilers are also naughty.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
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.In section [dcl.ref] of the C++ Standard:
A reference shall be initialized to refer to a valid object or function. [ Note: in particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the “object” obtained by dereferencing a null pointer, which causes undefined behavior. As described in 9.6, a reference cannot be bound directly to a bit-field. —end note ]
Yes, compilers typically implement references as "pointers with object semantics". This works fine when the reference is valid, but breaks the C++ programming model for a null reference. As I said before, relying on undefined behavior is a bad idea. I agree that your code will work for many (most? all?) C++ compilers, but that does not mean that it is good code. I reiterate that checking for a program that breaks the C++ programming model should not be done within the bounds of the C++ programming model; a lower-level mechanism must be used. EDIT: Beaten to the draw by Mladen
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
-
I agree that the naughty code should be trapped, but most compilers are also naughty.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.As a matter of fact compilers will already [optimize away that null reference check](https://godbolt.org/z/bP9q9h).
-
In section [dcl.ref] of the C++ Standard:
A reference shall be initialized to refer to a valid object or function. [ Note: in particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the “object” obtained by dereferencing a null pointer, which causes undefined behavior. As described in 9.6, a reference cannot be bound directly to a bit-field. —end note ]
Yes, compilers typically implement references as "pointers with object semantics". This works fine when the reference is valid, but breaks the C++ programming model for a null reference. As I said before, relying on undefined behavior is a bad idea. I agree that your code will work for many (most? all?) C++ compilers, but that does not mean that it is good code. I reiterate that checking for a program that breaks the C++ programming model should not be done within the bounds of the C++ programming model; a lower-level mechanism must be used. EDIT: Beaten to the draw by Mladen
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:
EDIT: Beaten to the draw by Mladen
Language lawyers are not much different than ambulance chasing lawyers :)
-
As a matter of fact compilers will already [optimize away that null reference check](https://godbolt.org/z/bP9q9h).
That's execrable if they're not trapping null references.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
In section [dcl.ref] of the C++ Standard:
A reference shall be initialized to refer to a valid object or function. [ Note: in particular, a null reference cannot exist in a well-defined program, because the only way to create such a reference would be to bind it to the “object” obtained by dereferencing a null pointer, which causes undefined behavior. As described in 9.6, a reference cannot be bound directly to a bit-field. —end note ]
Yes, compilers typically implement references as "pointers with object semantics". This works fine when the reference is valid, but breaks the C++ programming model for a null reference. As I said before, relying on undefined behavior is a bad idea. I agree that your code will work for many (most? all?) C++ compilers, but that does not mean that it is good code. I reiterate that checking for a program that breaks the C++ programming model should not be done within the bounds of the C++ programming model; a lower-level mechanism must be used. EDIT: Beaten to the draw by Mladen
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.
It is good code if it will fail gracefully under some compilers, and especially the one actually being used. But I agree that a lower-level mechanism is also needed.
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
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 BufferIt will close the gab between C# and database. Both will be able to deal with nullable and non-nullable types (as they already can for the C# value types). I.E. fewer hidden traps. So once the code is updated you will know if something can be null right from the types in your C# code, and your compiler will be able to point out you are an idiot, instead of having to run the code to learn it the hard way. :) Of course it will require a code change to update any existing C# entities.... just as you need to update the rest of the code. I do not think of enabling nullable check as "enable some more warnings". I see it as a late attempt to fix what I can only describe as a huge mistake in the C# type system. Splitting nullable off from the type just as databases did decades ago (well... Oracle did it wrong for strings, but still). Unfortunately it comes so late it still needs to live with the crappy code that isn't using nullable checks - so you will still need to throw ArgumentNullException from public types.
