[louthy]

> 1. It is possible to write reasonably "functional" applications in .NET. The only problem I had with that is lack of built-in copy-on-write data types and prevalent nullity.

I've tried to minmise that pain over the past few years with my 'functional language extensions' for C# [1].

It's a library with most of the common monadic types (as structs so there's no null issues); Immutable collection types that don't have an unweildy naming scheme like like the System.Immutable.Collections library - which are all structs, so no nulls; A type called 'Record<T>' which when you derive a type from it gives your type value-semantics (equality, ordering, GetHashCode, ToString, serialisation/deserialisation) by default; and tons more.

You still have to do stuff like build your own With method for immutable types. I have written of how these can be achieved _realtively_ easily [2]

C# has made great strides over the past 10 years to make it easier for those of us that want to work functionally to do it. It still has some way to go (discriminated unions, higher-kinds, record types, etc.) but it's already possible to write code functionally - you just need to do some boilerplate every now and then.

[1] https://github.com/louthy/language-ext

[2] https://stackoverflow.com/questions/38575646/general-purpose...

[Flow]

Wow, what a nice project you have there.

I've read that the next C# will have non-nullable reference types, have you thought about how to make your framework fit in with that? It's a "natural" Some/None in a way.

[louthy]

> Wow, what a nice project you have there.

Thanks :)

> It's a "natural" Some/None in a way.

If we lived in the perfect non-nullable reference world from the start then it's arguable whether Option<A> would ever have been needed - and so going forward it should be needed less, or not at all for some devs. The question comes when you need an optional value, and so you use nullable references instead of Option<A>. With nullable references the `null` still honours the contract of `A` - this is what Option<A> protects against. If the flow-analysis for nullable references is good enough to spot that you're possibly going to use null and then forces you to use a predicate of some sort (if/switch/ternary/...) to validate the referenced value exists then I think we're good. I understand that is what's planned, but it needs to be bulletproof.

There will be devs working in the nullable reference world for a long time (due to difficulties with moving to the new world when it comes) - and so I fully expect Option to be useful for its null protection reasons for a long time.

The story is a bit bigger than just protection against null though. If instead of seeing Option<A> as A|null, you see it as A|B, where B is the single-value type: Unit. Then Option is A|Unit. If you then look at Either<L, R> which is designed to represent one of two alternative values: L|R then it's pretty easy to see that Option is Either<Unit, A>. And then when we look at Try<A> which is designed to return A or capture an exception and return it as a value, then that can be seen as Either<Exception, A>...

All of the types that represent one of two values have lots of additional powerful functionality: Fold, Map, Bind, BiFold, BiMap, BiBind, etc. and have been designed to seamlessly switch between each, which won't exist on the standard nullable reference types. So, there's still a place for Option in the bigger scheme of things.

Personally, I can't wait for non-nullable references to come in. I built language-ext to try and get a handle on a 10,000,000+ line code base that kept falling foul to null reference exceptions (along with other common C# coding world problems). It was 100% to help me and my team build more robust code. Non-nullable references is a feature we will turn on immediately, even if it takes a week to fix up the warnings and errors it spits out, this is going to be one of the most important updates the C# team have done.