Option type implementation in C#

F# has this clever functionality called Option<'a>. This means that, instead of returning null from a function, you return an option. This option could have the value Some x or None, where x is the value you want to return, clearly indicating that this method could return a value or not.

let getIndexOfSubstring (s : string) (substring : string) =
    let index = s.IndexOf(substring)
    match index with
    | -1 -> None
    | n -> Some n

Function signature

val getIndexOfSubstring : string -> string -> int option

And for those of you not fluent in F#, this means that getIndexOfSubstring takes two strings and returns an option of int. This option could be Some int, or it could be None if the substring is not found. What you win, is that option is now part of the method signature. As a method invoker you will have to handle the None option. As with NULL references, a null return value is often a side effect of the method and often unexpected.

Implement Option<'a> in C

The option type is a type that we use as return value from a method.

public Option<int> GetIndexOfSubstring(string s, string substring)
{
    var index = s.IndexOf(substring);
    if (index == -1)
        return new None<int>();

return new Some&lt;int&gt;(index);

}

What does this mean?

1. The implementation clearly states that the method returns some value or no value at all.
2. If the return type is an option, you need to return both Some and None for the construct to be valid. The caller of this method expects that both Some and None are possible values.

The method signature also provides you with better test names.

[Test]
public void ShouldReturnSomeIndexForExistingSubstring()
{
    /* Test implementation */
}


[Test]
public void ShouldReturnNoneWhenSubstringDoesNotExist()
{
    /* Test implementation */
}

What are Some and None?

The example code makes much more sense if you look at the class diagram of Some/None.

The code for the option is very abstract.

// Used as return type from method
public abstract class Option<T>
{
    // Could contain the value if Some, but not if None
    public abstract T Value { get; }

public abstract bool IsSome { get; }

public abstract bool IsNone { get; }

}

We could implement IsSome/IsNone by comparing this type with Some/None class, but I don't like the idea of a superclass reference any subclass. The implementation of Some and None are pretty straight forward.

public sealed class Some : Option
{
 private T value;
 public Some(T value)
 {
  // Setting Some to null, nullifies the purpose of Some/None
  if (value == null)
  {
   throw new System.ArgumentNullException("value", "Some value was null, use None instead");
  }


this.value = value;
 }

public override T Value { get { return value; } }

public override bool IsSome { get { return true; } }

public override bool IsNone { get { return false; } }
}

public sealed class None : Option
{
 public override T Value
 {
  get { throw new System.NotSupportedException("There is no value"); }
 }

public override bool IsSome { get { return false; } }

public override bool IsNone { get { return true; } }
}

Creating a Some instance with null value is only ridiculous, and that is why we throw an exeption. The same goes for calling Value on None.

How do you call a method that returns Optioni<T>?

Here is some code that will call my first example and act differently if the result is Some or None.

// Get string before substring
private string SubstringBefore(string s, string substring)
{
    var operations = new StringOperations();
    var index = operations.GetIndexOfSubstring(s, substring);

if (index.IsSome)
    return s.Substring(0, index.Value);

return s;

}

What are the benefits of the calling method?

• The result must immediately be checked if it is Some/None before you start using the value. Of course you could ignore the check and go directly to index.Value if you're willing to take the exception when index is None. (just like null values)

• It's clear for the reader that GetIndexOfSubstring might not return a value and that has to be dealt with.

Using Optioni<T> with reference types

Value types like int already have this functionality with Nullable. Nullable works the same way with a different purpose, to give value types a null value. With value types it is quite clear that "null" means "no value", but with reference types it could mean

• Abscense of value. The method states that for given input there is no output value.
• Empty set. Specially working with databases, null could mean that the result set was empty.
• Unknown. The method does not know how to respond and throw us a null (when it really should throw an exception)
• Not initialized. An object has not been initialized and the reference is null.

The real danger of null in .NET is when it comes from the framework or a third part library and we where not expecting it. That is when you'll see the NullReferenceException, the most - and it could pop up at any time in production. This is why we don't allow null values into Some. Better to fail early when we're creating the result set of the method, than letting the program run in a faulted state until it tries to use that value.

public Option<User> FindUserByName(string name)
{
 var query = from user in Users
    where user.FirstName.Contains(name) || user.Surname.Contains(name)
    select user;


var found = query.FirstOrDefault();
 if (found == null)
  return new None<User>();

return new Some<User>(found);
}

What has to be noticed in this example, is that found really have to be checked for null before entered into Some, or it may blow up. This means that Some/None null checks would be all over the place violating DRY. Could we fix it with an extension method?

404: Not Found

And this changes the previous example to.

var found = query.FirstOrDefault();
return found.SomeOrNone();

When is it elegible to return Some<T> instead of Option<T>?

When we have a reference return type that we want to communicate, "could never be null", we could use Some as the return type, but this would feel a bit weird at the method invokers end. You could communicate the same thing with Microsoft Code Contracts.

Here's really three possible state of Option<T>, Some/None and Null. How do I protect myself from a method with Option<T> return type, from returning null?

Microsoft Code Contracts is also the answer here, or you could look into AOP and write an aspect that will throw an exception when you try to return null instead of an instance of Option. If you've decided on the method signature, you probably also agree on the pattern Some/None. But the method signature could be forced upon you with an interface, and in that case some security measure that makes sure that you don't return null could be useful. All the source code in a nice packaged VS2010 solution can be downloaded from here.