2 Replies - 138 Views - Last Post: 16 February 2019 - 12:40 AM

#1 Skydiver   User is offline

  • Code herder
  • member icon

Reputation: 6772
  • View blog
  • Posts: 23,076
  • Joined: 05-May 12

Nullable Reference Types in C# 8.0

Posted 15 February 2019 - 05:31 PM

Thanks to the other thread which mentioned C# 8.0's support for Indexes, I stumbled across another one of the C# 8.0 planned features: Nullable Reference Types.

When I was first reading the first few paragraphs of the MS blogpost, the back of my mind kept on imagining trying to comply with is would be just like trying to do C++ const-correctness.

I had to take a break from reading that post and have some lunch. While having lunch, I tried reading something less dense. I was gratified to realize that I was correct in what I was envisioning when I was reading Jon Skeet's blog post where he talks about his experience of implementing the necessary changes in one of the libraries that he maintains.

Quote

Fixing these warnings didnít take very long, but it was definitely like playing Whackamole. You fix one warning, and that causes another.

and

Quote

The more repetitive part is fixing all the tests that ensure a method throws an ArgumentNullException if called with a null argument. As thereís no compile-time checking as well, the argument
needs to be null!, meaning ďI know itís really null, but pretend it isnít.Ē It makes me chuckle in terms of syntax, but itís tedious to fix every occurrence.


Anyway, I tend to agree with Microsoft's intent of making coding safer by implementing this feature, but ripping the band-aid off is going to be as painful as hell. To make matters worse, even if I were proactive and started fixing my code, and tried guessing at what the libraries that I depend on would do, I would still have to do a second, or third pass as I get versions of my dependencies which also implement the stricter null checks.

Or maybe I'm looking at this with the wrong approach? Should I not rip off the band-aid, but instead just litter my code with tons of #nullable enable and #nullable disable as I touch files. Eventually, I'll replace the last #nullable disable with #nullable enable.

What are your thoughts about this new language feature?

Is This A Good Question/Topic? 1
  • +

Replies To: Nullable Reference Types in C# 8.0

#2 Martyr2   User is offline

  • Programming Theoretician
  • member icon

Reputation: 5360
  • View blog
  • Posts: 14,258
  • Joined: 18-April 07

Re: Nullable Reference Types in C# 8.0

Posted 15 February 2019 - 06:11 PM

I have always thought C# is going down too many rabbit holes with all these syntax changes they have made over the years. The C# I started with years ago is very different than it is today littered with its syntax sugar. Now programmers can write code that just completely destroys readability with all the shortcuts they have introduced.

I see what they are trying to do with this, but a language shouldn't be trying to protect the developer from making bonehead mistakes (only from making mistakes that are incredibly hard to find... hence garbage collection for the win). Programmers need to stop being lazy and make the appropriate checks if something is null before using it. I mean, how hard is it to do a simple null check? if (blah == null). Done!

I guess to answer your question, you could very well rip off the band-aid only to find they have implemented another band-aid underneath. The way they are running that language it very well could be another issue later that will force you to change again. I tend to stick with the middle of the road stuff that works and try to avoid needing things like nullable types. Declare what you mean, make it obvious, do your checks before using and you should be fine in any language.

:)
Was This Post Helpful? 1
  • +
  • -

#3 ndc85430   User is offline

  • I think you'll find it's "Dr"
  • member icon

Reputation: 972
  • View blog
  • Posts: 3,839
  • Joined: 13-June 14

Re: Nullable Reference Types in C# 8.0

Posted 16 February 2019 - 12:40 AM

I'm not a C# programmer, but I had a brief look at the article and the approach seems similar to that used in Kotlin (docs: http://kotlinlang.or...ull-safety.html). I think having null safety is a good thing, but I prefer it in the form of an option type that I can map or flatMap on in the same way I'd do on a List, Either or Future in Scala.

This post has been edited by ndc85430: 16 February 2019 - 03:02 AM

Was This Post Helpful? 1
  • +
  • -

Page 1 of 1