Proposal: Maybe<T>/Option<T>

[ElemarJR]

public Option<Employee> GetById(string id)
    => new DbContext().Find(id);

instead of

public Employee GetById(string id)
    => new DbContext().Find(id);

The proposed method signature reveals much better the real intent of this method/function. Right?

Option<T> could provide a Match function....

This proposal does not incur any CLR changes.

[HaloFour]

@ElemarJR

Also doesn't involve any language changes. You could create an Option<T> or Maybe<T> type today. If you want the BCL to consider adding one, you might want to try requesting that in CoreFX repo.

[ElemarJR]

I have been using my own type for a long type. But you are right, the right repo would be CoreFX.

Link to CoreFX related issue:

https://github.com/dotnet/corefx/issues/18159

[huoyaoyuan]

I think the better solution is nullable reference types.
Pattern match is good, but in this scenario it's more of a hindrance than a help. Compiler-recognized null check is proposed together with nullable reference types. Introducing a wrapper gives the compiler more thing to do magic on, or lowers the performance.

[DavidArno]

@huoyaoyuan,

Reference types are already nullable. And nullable values are a very poor replacement for maybe types.

[huoyaoyuan]

@DavidArno in fact we are adding non-nullable references (for code analysis). Nullable ones are also concept for code analysis. They are not runtime-level concept at all.

[GeirGrusom]

Please no. My experience with Java is that the option type creates a lot of noise. It's a feature much better handled by the language, or at least not by a type on its own.

[DavidArno]

@huoyaoyuan,

in fact we are adding non-nullable references (for code analysis)

I'm not sure I'm following you. What do you mean by "in fact we are adding non-nullable references..."? I thought non-nullable refs were still in the "the team might do it, one day" stage? I'm also unsure what you mean by "code analysis" here. Non-nullable types will allow folk to avoid having null come anywhere near their code. This is a seriously important feature for many of us. To my mind at least, the phrase "nullable refs" is deeply disturbing as it suggests people have missed the point entirely and see it as a way of using T? everywhere in their code.

Option<T> and Nullable<T> are simply not comparable. They serve very different purposes. It's like comparing chalk and quantum mechanics. Returning a T? from a TryX() method would just be plain silly as the result may be null, so the usual crappy null checks are still needed. Using a Option<T> to hide a null returned from a DB query for example, would also be silly. Use the correct tool for the job.

[DavidArno]

@GeirGrusom,

Java's use of Option<T> must be severely broken then. May I suggest you check out how F# uses such types? It'll open your eyes to a wondrous world of possibilities...

[huoyaoyuan]

@DavidArno

Option<T> and Nullable<T> are simply not comparable. They serve very different purposes.

They are for the same purpose, and in F# there's one type option for it. The only difference is how the runtime treats them.

[GeirGrusom]

@DavidArno

We don't need a type to indicate nullability because all types reference types are nullable in .NET. What we need is to have the C# compiler be able to issue warnings for missing null checks on return types annotated with CanBeNull and syntactic sugar to add this annotation.

With ?. and ?? most of the important Option type use cases are already covered.

[DavidArno]

@huoyaoyuan,

You are mistaken. Please see, for example, details of F#'s nullable operators. F# has to interop with the rest of .NET, so has to handle null and nullable values.

Sure, any self-respecting (F#) developer will only go near null when they have to, but nullable values are there for when needed, for they have specific use-cases that options don't cover well. Option<T> is there for all other cases.

@GeirGrusom,

We don't need a type to indicate nullability because all types reference types are nullable in .NET

Clearly we do, as otherwise Nullable<T> wouldn't exist. At times, one needs to handle null for values. Admittedly, as options and pattern matching still aren't commonly used by C# devs, many use nullable types to emulate options, but proper option types are superior in these cases, as they avoid null and avoid information loss when the reference itself is null:

var x = (new List<string>()).FirstOrDefault();
var y = (new List<string>{null}).FirstOrDefault();
// x == y: we have information loss

var x = (new List<string>()).TryFirst();
var y = (new List<string>{null}).TryFirst();
// x == none; y == null. No information has been lost.

[GeirGrusom]

Clearly we do, as otherwise Nullable wouldn't exist.

Nullable<T> is for value types, which can't on their own have a distinct null value.

as they avoid null

No they won't, and they can't.

but proper option types are superior in these cases

Why? Why is a specific Option type superior to using the already defined nullable reference type (which I would claim is the exact same thing as an Option type)? Implement operators and pattern matching in the language for reference type rather than adding a wrapper type to indicate the exact same thing one more time. What we need is to be able to warn about non-null checked nullable values. We don't need option types because it already exists.

Today we have ?. and ?? which mostly covers flatmap and none. What other features do you need? Couldn't it be implemented in pattern matching rather than adding a boilerplate type?

[DavidArno]

@ElemarJR,

IMO this proposal is in the wrong place (DUs and other closed type hierarchies should be directly supported in the CLR and options, either and other common DUs should be supported by the BCL). However, it's become clear that folk are downvoting this, not because of that reason, but simply because they don't understand the purpose of options. As such, I've therefore upvoted it to counter that.

[GeirGrusom]

but simply because they don't understand the purpose of options.

No one is confused about that. You're just parroting the option type from another language instead of analyzing how nullable types work in C# and trying to improve on that instead. Duct taping another nullability layer on the already existing nullability pattern is, in my opinion, a very bad idea, and I think Java's Optional<T> perfectly shows it.

[ElemarJR]

The purpose of Option<T> is to make clear that something could have no value. Today all methods returning objects could potentialy to return null. Right? There is no way to say that there is guarantees that the method will return a Object every time. In the other side, there is no way to say that a method could, by design decision, return null. The implications of this fact is that we have to adopt a defensive approach all the time, but,... sometimes people do not follow this strategy. NullReferenceException is so common that there is no way to say that the "null" is a good idea. Option<T> and other elevated times like Either<L, R>, would help us to write code with less mistakes. Why? Because we would have the opportunity to better express our intention in the code making everything clearer. Em qua, 19 de abr de 2017 às 06:41, Henning Moe <notifications@github.com> escreveu:

…

but simply because they don't understand the purpose of options. No one is confused about that. You're just parroting the option type from another language instead of analyzing how nullable types work in C# and trying to improve on that instead. Duct taping another nullability layer on the already existing nullability pattern is, in my opinion, a *very* bad idea, and I think Java's Optional<T> perfectly shows it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/dotnet/csharplang/issues/426#issuecomment-295190525>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGd8qexYX7YDK_5QKzESV39ZnNsWvQOks5rxda8gaJpZM4M44NF> .

[DavidArno]

@GeirGrusom,

Why? Why is a specific Option type superior to using the already defined nullable reference type (which I would claim is the exact same thing as an Option type)?

I've already shown you example: the information loss that FirstOrDefault suffers from. Yet, despite that, you are still claiming they are the same. A type that suffers information loss and another that doesn't are different. It is asinine in the extreme to argue the counter to this fact. And as for ?. being all that's needed to replicate options, consider:

var x = SomeThing.?Method1().?Method2();

here, if SomeThing is null, then Method1 and Method2 are never invoked. You can't chain methods with .?, regardless of value, you can just prevent them breaking when null creeps into the code. Whereas:

var x = anOption.Method1().Method2();

avoids those problems of null, avoids the need to protect again it at every step (or risk the code falling over in a heap) and ensures that Method1 and Method2 are always invoked. Just the fact that null is being avoided makes options superior, but they just keep giving beyond this for they offer so many advantages.

The fact that you makes statements like "duct taping another nullability layer on the already existing nullability pattern is, in my opinion, a very bad idea" shows you are indeed ignorant of the purpose of options. You prove my own point for me.

[GeirGrusom]

Yet, despite that, you are still claiming they are the same

var x = (new List<Option<string>>()).FirstOrDefault();
var y = (new List<Option<string>>{null}).FirstOrDefault();

Now where's your god? ;)

It will return the same thing twice if Optional is a value type, and if it's a reference type it return null or Optional<string>(null).

[DavidArno]

public struct Option<T> ...

var y = (new List<Option<string>>{null}).FirstOrDefault(); // Error. Option can't be null

Your move...

[GeirGrusom]

public class Foo
{
   public Option<string> Name { get; set; }
}
// ...
var f = new Foo();
var emptyList = new List<Option<string>>();
var list = new List<Option<string>>(f.Name); // Ops! default initialization will be a null option.

We just end up with two ways stuff can be defined as not having a value.

[louthy]

@GeirGrusom You seem mightily confused about Options for someone who claims to not be confused by Options.

Could I invite you to check the README for my library which discusses the need for Option and how all of your assertions so far are incorrect.

Link: https://github.com/louthy/language-ext/ --- scroll down to "Null reference problem"

var list = new List<Option<string>>(f.Name); // Ops! default initialization will be a null option.

Depending on the Option implementation you can get null to mean None. In my library I have Option which will refuse to store a null value and always set its state to None if it's ever initialised with a null value. And OptionUnsafe which is there for the times when Some value of null is what you want to represent, and None means 'no result'. These are all valid states.

And just to be clear, default initialisation of structs allows for creating an Option in a None state. So default(Option<string>) would give you a Option<string> in a None state.

    public struct Option<A>
    {
        public readonly bool IsSome;
        readonly A Value;

        Option(A value)
        {
            IsSome = value != null;
            Value = value;
        }

        public static readonly Option<A> None = default(Option<A>);
        public static Option<A> Some(A value) => new Option<A>(value);
        public static implicit operator Option<A>(A value) => new Option<A>(value);

        public B Match<B>(Func<A, B> Some, Func<B> None) =>
            IsSome
                ? Some(Value)
                : None();
    }

[GeirGrusom]

Look at Kotlin. It doesn't use a Option type for nulls, but it does basically have it, but it's all in the compiler.

fun getFoo() : Foo? -> ...
fun getFoo2() : Foo? -> ...
fun doFoo(v: Foo) -> ...
val f = getFoo() ?: getFoo2();
if(f != null)
{
  doFoo(f);
}

Kotlin will change the type of f inside the if scope to a non-nullable type. Forget the if test and the code simply won't compile.

C# probably can't give an error, but it could give a warning. I would much rather have that than an Option type. Option types cannot be removed when nullable references are introduced.

There is absolutely no chance of NullPointerException or ValueWasNullException in this code. It's completely null safe, and that without a Option type.

[DavidArno]

@GeirGrusom,

Option types cannot be removed when nullable references are introduced.

1. References are already nullable. I think you mean "when non-nullable reference types are introduced". This talk of "nullable references" is both telling and depressing: it implies you'll be fighting non-nullable references by using Foo? throughout your code to keep null alive.
2. Non-nullable reference types and options are not the same thing, nor is your Kotlin code using options: it's being forced to do null checks because you are leaking nulls out of getFoo and getFoo2. Since options serve a different purpose, of course they won't be removed. F# already has that same type safety around nulls as Kotlin, but it has options built-in, because they serve a different purpose.

And of course, if we fix your Kotlin code, the whole need to check for null goes away:

fun getFoo = () : Foo -> ...
fun getFoo2 = () : Foo -> ...
fun doFoo = (v: Foo) -> ...
val f = if (someCond) getFoo() else getFoo2();
doFoo(f);

There is absolutely no chance of NullPointerException or ValueWasNullException in this code. It's completely null safe, and that without a Option type.

Indeed. It achieved that without using a lemon sorbet as well. That's because non-nullable references are different things to both lemon sorbets and options.

[GeirGrusom]

Nullable references was proposed by Andres Heljsberg and the idea is that it's more useful to indicate that something is nullable than the other way around. .NET has null, It will insert null when it bloody well pleases and that's a underlying machine functionality. It's completely unavoidable. You're just hiding them inside an abtraction that throw ValueWasNullException instead.

Make the compiler enforce the runtime's rules about null rather than padding on an ugly abstraction on top.

[louthy]

@GeirGrusom Why do you keep ignoring what @DavidArno is saying to you?

• A nullable reference is not an Option type. An Option type represents an optional value. i.e. it is either there or it is not.
• A nullable reference (the current default) is either a value or a null, but there is no indication in the type system whether the value should be null, could be null, or is never going to be null. And therefore it's a ticking time-bomb of a type.
• A non-nullable reference is guaranteed to not be null. It currently doesn't exist in C#. But even if it did, it wouldn't help avoid the situation where an optional type is required. When an optional type is required, we want null to not honour the contract of its type: that is what None does.

.NET has null, It will insert null when it bloody well pleases

No it won't. Stop making stuff up. This is just not true.

and that's a underlying machine functionality

The underlying machine bears no relevance here. The CLR and the language implementation is what matters.

You're just hiding them inside an abtraction that throw ValueWasNullException instead.

No he's not. It's perfectly possible to have a type-safe Option that never carries a null. I showed you an example of it above. Make the type a struct, and make null always put the Option in a None state. If you think I'm wrong, get my example Option implementation from above and tell us all how you can break it.

I have actually taken a look at some of your code on your repository, and frankly I'm very surprised that you don't understand what the problem is. Take a look at this function from your SimpleConfiguration project:

    [return: NotNull]
    public static  string GetValue([NotNull] this IConfiguration config, [NotNull] string key)
    {
        if (key == null)
        {
            throw new ArgumentNullException(nameof(key));
        }

        string value = config.TryGetValue(key);
        if (value == null)
        {
            throw new MissingConfigurationKeyException(key, config);
        }

        return value;
    }

The thing is cluttered with attempts to deal with null and to communicate failure (no value). Option deals with that.

This would be my GetValue implementation (using Map from lang-ext as the config store):

    public static Option<string> GetValue(Map<string, string> config, string key) =>
        config.Find(key);

Map<A, B> is a struct, and therefore can't be null, key could be null, but Find will return None if that is the case. There's no need for expensive exception throwing, or repetitive null checking. It is safe, and most importantly: The programmer can see in the signature what to expect:

    Option<string> GetValue(Map<string, string>, string)

[MovGP0]

The CoreFx issue #18159 seems to be a better place do discuss Maybe monads, except you propose some special syntax for it.