Matt Swanson made a post[1] on his blog concerning the Optional type[2]. I think it’s pretty good; go ahead and read it. The gist is that the Optional type allows a programer to communicate the intent behind a parameter in a function. A function utilizing an optionally typed parameter is telling any consumers of that function that the parameter being passed in may or may not exist and the function will handle both of these cases appropriately. This is a much better state of affairs than simply having null parameters; we can be certain that passing in “Nothing” is an acceptable option without having to view the source code of the function we are using.
Personally, I think our industry has some issues it needs to take care of concerning the comprehensibility of API functions. This means that I am very interested in anything that better ensures the correct usage of functionality where the source code is either not available or not easy to access. So I’m also an endorser of the Optional type for the reasons that Matt mentioned.
However, there are also some interesting properties you get with the Optional type beyond communicating intent. For example, perhaps you’re concerned that someone is going to misuse an instance of an Optional by simply grabbing out the encapsulated value without checking to see if the value actually exists. Maybe you’re writing an API or maybe you’re just very prone to worrying. Well consider an Optional class written as follows:
class Optional<T>
{
private readonly T _value;
private readonly bool _hasValue;
public Optional( T value )
{
_value = value;
_hasValue = true;
}
public Optional()
{
_hasValue = false;
}
public S Extract<S>( Func<T, S> valueExists, Func<S> noValue )
{
if ( _hasValue )
{
return valueExists( _value );
}
else
{
return noValue();
}
}
}Now there isn’t any choice. The only way to access the value is to pass two functions into the Optional instance. One function handles the case where the value exists and the other one handles the case where the value does not exist. Of course this isn’t very idiomatic C# code, but the semantics is actually very similar to what happens in languages with pattern matching [3]. In languages with pattern matching this sort of thing has a convenient and idiomatic syntax as well as better compiler warnings/errors.
Additionally, there are other powerful concepts that go hand-in-hand with Optional. Functors and applicative type classes[4] (although the concept is available in any language with higher order functions) allow you to “lift” a normal function that doesn’t handle Optional typed parameters and automatically transforms it into a function that is able to handle Optional typed parameters. Also the monad type class (also a concept available in any language with higher order functions, but typically you will want a language that has a supporting syntactic sugar such as F# or Haskell) allows you to automatically handle many possible Optional typed variables implicitly.
Overall, I feel that the Optional type holds many benefits for the future of Software Engineering.
[1] – https://www.mdswanson.com/blog/2015/03/17/what-is-the-point-of-optionals.html
[2] – This is of course talking about the Optional type (also known as the Maybe type) that shows up in languages like F# or Haskell. Optional parameters is a separate feature which is similar, but has significant differences.
[3] – F#, Haskell, Ocaml, etc
[4] – A type class is an interesting feature in Haskell that allows a specific function to be selected based off of the type of a variable. It’s similar to function overloading in languages like C# or Java. Other languages have started to add in similar features (ex. F# has computational expressions).
