Language-ext: Use c# 8.0 and enable nullable reference

[iron9light]

You can enable c# 8.0 and Nullable reference types with dotnet core 2.2 .
Just add lines below to the project file:

<PropertyGroup>
  <LangVersion>8.0</LangVersion>
  <Nullable>enable</Nullable>
  <!-- NullableContextOptions will be replaced by Nullable in dotnet core 3.0 -->
  <NullableContextOptions>enable</NullableContextOptions>
</PropertyGroup>

Handling nullable is a very important part of this lib. I with it could work smoothly with the new "Nullable reference types".
And I with this lib can support something like Option<string?>.

[louthy]

Yes, it’s on my list :)

[avonheimburg]

Would any help be appreciated? I could give it a go

[avonheimburg]

How would we want to handle nullables in general? Should we continue disallowing null-values (except for the *Unsafe-types), or, as null handling is finally somewhat sane, should we start allowing null-values iff the type is a nullable? (That is, Some could be Some(null), while a Some couldn't)

[louthy]

@avonheimburg I have a branch where I have started the process, unfortunately Visual Studio with the C#8 pre-release was causing my typing speed to drop to about 1 character per second, and so I had to bail. It's not as trivial a task as I had originally hoped either, so I've paused it for the moment.

How would we want to handle nullables in general?

It's an open question, and one I haven't entirely clarified in my own mind now. My concern is what happens to the people not on C# 8 if I start removing all of the null checks. I don't think there's any clear guidance on how to support the past and the future (in a library), and that's a big deal for this library in particular.

[louthy]

Would any help be appreciated?

It would definitely be appreciated, but I think first I'll need to do some more research into the issues I raised above. If anyone has any ideas on this then I'm open to hearing them.

[avonheimburg]

As far as I can see, we would only need some syntactic / project settings changes so we don't get tons of errors when client libraries trying to compile with nullable reference types enforced. The logic - checking for null and allowing or disallowing it - would keep working the same way it does currently. For that, we would need to set nullable-support to "warning only", correct the warnings appropriately and maybe accept a T? where appropriate. Also, ...unsafe-methods would need to have return a T? instead of a T, but again, this doesn't change their behaviour for older versions of dotnet.

The more interesting question is: Now that we have nullable reference types, do we want to start allowing null iff the type is a nullable? Is Some(null) a valid construct if the type is, for example, a string?. You could argue that since the fact that it can be null is now encoded in the type, null is actually a value that makes perfect sense for a string? as opposed to a string, so we should allow it. This could be achieved internally by allowing null if the type is a Nullable<>. However, this fundamentally changes the way LanguageExt deals with nulls, so may not be desired.

The most radical, but certainly not backwards-compatible option would be to do away with Option entirely, using T? everywhere instead (since conceptually, None and null kind of mean the same thing). This would allow for the most seamless integration with nullable reference types at the cost of not integrating well (or at all) with projects where nullable reference types are not supported. Obviously, this approach is out of the question, but I thought I'ld add it.

I'm game for exploring either of the first two options.

[avonheimburg]

Thinking about it further, I think allowing null for nullable types is the way to go. If I create, say, a Lst, i would reasonably expect null to be allowed, as the type signature _explicitly_ states that null is a possible value. The whole logic of we-musn't-allow-null-since-the-type-is-not-clear-on-whether-it-can-be-null no longer applies.

[StefanBertels]

Just my 2 pence: I like the library features for Option<T> especially things like LINQ support (bind). C# 8 will make nullables safer but I personally think that I want to stay with Option<T>. This way I can use e.g. Sequence and Traverse in a very generic way.

I guess it will be very hard to make T? work like Option<T>. Maybe we could allow implicit casting from T? to Option<T> and maybe back (?).

[maxbog]

Hi! Is anything happening in this context?

[louthy]

@maxbog Not until the code-gen can be migrated to .NET Core 3.

https://github.com/louthy/language-ext/pull/754

It'll be probably a month until I do another full release. After that I may look into it, but there are complications due to the opinionated aspects of lang-ext.