tejacques/option

An Option type for C#

option's Issues

Consider renaming/deprecating of 'ForEach' into 'Apply'?

I am aware of the benefits of having the 'Option'-type implement IEnumerable. However, is there a specific reason why the 'ForEach'-method is titled as such? In a codebase I'm currently working in it unfortunately conflicts with a 'roll-your-own'-implementation of a LINQ-style 'ForEach'-extension method.

My opinion is obviously subjective and biased, but I was wondering why the name 'ForEach' was settled. I could not find 'ForEach' being used in F# either. 'Apply' feels like the better choice.

I love this library though; it's awesome!

Consolidate access to Option's value

Currently, there are 7 methods to use the value in an option:

1) TryGetValue

if(option.TryGetValue(out value))
{
    /* use value */
}

2) HasValue and Value

if(option.HasValue)
{
    var val = option.Value;
}

3) ValueOrDefault and ValueOr

var value = option.ValueOrDefault;
value = option.ValueOr(1);
value = option.ValueOr(() => 1)

4) Match method using Some and None arguments

option.Match(None: () => {}, Some: value => {});

5) LINQ style IEnumerable interface

option.Select(value => value);

6) Match method using Some and None fluent API

option.Match()
    .None(() => {})
    .Some(value => {})
    .Result();

7) Match method using overloaded | and implicit conversions

var matched = option.Match()
    | value => value
    | () => 0;

I believe that there is value to having multiple ways to access the data, because it allows you to pick the one most natural for the situation. That said, some of these methods are clearly inferior and can lead to a lot of the issues the Option type is supposed to help prevent.

The option type should help prevent these things:

1. Runtime errors (NullReferenceException). These should be caught at compile time
2. Non-exhaustive matching. The Option type should force the user to properly handle all cases. These should also be caught at compile time.

Access to the Option's value through option.Value does not prevent runtime exceptions, thus it should be removed.

The functional style OptionPatternMatcher also doesn't prevent runtime errors or non-exhaustive matching, in addition to having a syntax which looks like another language (more like F# or ML, which isn't bad, but is confusing to users of the library in C#). If there was compiler support for it, I would leave it in, but because there isn't, and it does still have runtime errors, they should be removed.

Therefore we should remove the 2nd, 6th and 7th methods for accessing the value of the option. This will consolidate the methods down to 4.

To help migrate projects using these styles, we should release a 3.1.0 version which marks these as obsolete with instructions on how to restructure the code. Once this version is released, in the wild for an appropriate amount of time, a 4.0.0 library should be released which removes these.

Option should be value type

Since your implementation doesn't use class hierarchy (like MayBe from FunctionalCSharp does), it should be struct (like Nullable). It will at least protect from NullReferenceExceptions which is the goal of maybe/option types in Scala and F#.

Remove implicit conversion from Option<T> to T

This should be removed because it isn't a safe operation. Instead use one of the following if a value is required:

• Option.ValueOrDefault
• Option.ValueOr(T value)
• Option.ValueOr(Func<T> value)
• Option.Match(Func<TResult> None, Func<T, TResult> Some)

.NET Core /NetStandard support

It should be easy to compile source code against .netstandard1.1 target, since it only references BCL.

OptionPatternMatcher can overload | operator to make using it more functional style

I have mixed feeling about doing this, but it's neat. In order to use it, you need to wrap the lambdas in parens, because otherwise C# doesn't know what to bitwise OR | together

let o = Some(1)

let m = match o with
    | None -> "None"
    | Some(i) -> string i

Option<int> o = 1;
var matcher = o.Match()
    | ((i) => { /* Do something */ })
    | (() => { /* Do something else */ });

Func<string> m = () => o.Match<string>()
    | ((i) => i.ToString())
    | (() => "None");

Option shouldn't be in the System namespace

This isn't best practice in case Microsoft implements an official version in the future.

Option<T> should implement IEnumerable<T>

If we do this, we can take advantage of LINQ on the Option type.

Add Some type which implicitly converts to an Option with a value

Idea from: https://github.com/louthy/language-ext

This allows for runtime checked Non-null types.

Update NuGet package

Please, update Option NuGet package, the last published version is 2.0.2, but I want to use "null-safe" version. Thanks

.NET 4.0 binary

I am currently stuck on .NET 4.0. Can you provide a binary for it on NuGet?

Option LINQ functions should return Options rather than other IEnumerables

This makes them more Scala-like.