|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
To be aware of it is the first step 
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.
|
|
|
|
|
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
|
|
|
|
|
Daniel Pfeffer wrote: a reference can never be null
They're not supposed to be null, but they can be. If someone passes *ptr as an argument, and ptr is nullptr, defensive code still has to include if(&ref == nullptr).
modified 16-Dec-20 9:06am.
|
|
|
|
|
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 nullptr reference 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.
|
|
|
|
|
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]
The point is you cannot reason about UB.
|
|
|
|
|
I agree that the naughty code should be trapped, but most compilers are also naughty.
|
|
|
|
|
|
That's execrable if they're not trapping null references.
|
|
|
|
|
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 
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
Pointless. Used by inferior practitioners.
|
|
|
|
|
PIEBALDconsult wrote: Pointless
So are circles, but I still use them. 
|
|
|
|
|
I suspect enabling this will wreak havoc on all the entity models with string properties where the backing field in the DB is nullable. 
|
|
|
|
|
That'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
|
|
|
|
|
It 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.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
