<commit_before># Maybe
A covariant implementation of the option pattern for .NET 4.5.

**Note: this is not currently an implementation of the Maybe Monad, nor should it ever be.**

The development of this project was motivated by a need (in my own work) to eliminate ambiguity in *suggested* behavior for interface members.

Consider the following:

```csharp
public interface ILookStuffUp<TKey, TItem>
{
    TItem Lookup(TKey key);
}
```

A consumer of this interface may want to know a few things about the behavior of `ILookStuffUp.Lookup`:

* Will `Lookup` return the default value of `TItem` if the key does not exist?
* Will `Lookup` throw an exception if the key does not exist?
* If `Lookup` throws an exception, which one will it be?

We could address these questions in the comments, like ...

```csharp
public interface ILookStuffUp<TKey, TItem>
{
    /// <summary>
    /// Look something up!
    /// </summary>
    /// <returns>
    /// The value associated with the current key, or the default value for the type if the key does not exist.
    /// </returns>
    TItem Lookup(TKey key);
}
```

In the above, the consumer can be *reasonably* assured that an exception won't be thrown.

But consider:

```csharp
public interface ILookStuffUp<TKey, TItem>
{
    /// <summary>
    /// Look something up!
o    /// </summary>
    /// <returns>
    /// The value associated with the current key.
    /// </returns>
    /// <exception cref="System.InvalidOperationException"/>
    /// Thrown in the event that the given key does not exist.
    /// </exception>
    TItem Lookup(TKey key);
}
```
N
Here, the opposite approach was taken, and now the consumer can be *reasonably* assured that an exception *will* be thrown if the key does not exist.

There's still one major problem: no matter what the contract says about how things *should* happen, **its up to the implementor to ensure that their implemented behavior matches the intended behavior**.

Even if we did the following:

```csharp
public interface ILookStuffUp<TKey, TItem>
{
    /// <summary>    /// Look something up!
    /// </summary>
    /// <returns>
    /// The value associated with the current key. Implementations SHOULD return the default value for
    /// the type in the event that the given key does not exist. Please see RFC 2119 for a conforming
    /// definition of the word, 'should'.
    /// </returns>
    TItem Lookup(TKey key);
}
```

Here we've been (painfully) descriptive of our intent, even to the point of leaking a desperate plea into the source. But our original problem still exists, and the ultimate behavior of the `Lookup` method is still up for grabs.

But how about this?<commit_msg>Removed stray character from README<commit_after># Maybe
A covariant implementation of the option pattern for .NET 4.5.

**Note: this is not currently an implementation of the Maybe Monad, nor should it ever be.**

The development of this project was motivated by a need (in my own work) to eliminate ambiguity in *suggested* behavior for interface members.

Consider the following:

```csharp
public interface ILookStuffUp<TKey, TItem>
{
    TItem Lookup(TKey key);
}
```

A consumer of this interface may want to know a few things about the behavior of `ILookStuffUp.Lookup`:

* Will `Lookup` return the default value of `TItem` if the key does not exist?
* Will `Lookup` throw an exception if the key does not exist?
* If `Lookup` throws an exception, which one will it be?

We could address these questions in the comments, like ...

```csharp
public interface ILookStuffUp<TKey, TItem>
{
    /// <summary>
    /// Look something up!
    /// </summary>
    /// <returns>
    /// The value associated with the current key, or the default value for the type if the key does not exist.
    /// </returns>
    TItem Lookup(TKey key);
}
```

In the above, the consumer can be *reasonably* assured that an exception won't be thrown.

But consider:

```csharp
public interface ILookStuffUp<TKey, TItem>
{
    /// <summary>
    /// Look something up!
o    /// </summary>
    /// <returns>
    /// The value associated with the current key.
    /// </returns>
    /// <exception cref="System.InvalidOperationException"/>
    /// Thrown in the event that the given key does not exist.
    /// </exception>
    TItem Lookup(TKey key);
}
```

Here, the opposite approach was taken, and now the consumer can be *reasonably* assured that an exception *will* be thrown if the key does not exist.

There's still one major problem: no matter what the contract says about how things *should* happen, **its up to the implementor to ensure that their implemented behavior matches the intended behavior**.

Even if we did the following:

```csharp
public interface ILookStuffUp<TKey, TItem>
{
    /// <summary>    /// Look something up!
    /// </summary>
    /// <returns>
    /// The value associated with the current key. Implementations SHOULD return the default value for
    /// the type in the event that the given key does not exist. Please see RFC 2119 for a conforming
    /// definition of the word, 'should'.
    /// </returns>
    TItem Lookup(TKey key);
}
```

Here we've been (painfully) descriptive of our intent, even to the point of leaking a desperate plea into the source. But our original problem still exists, and the ultimate behavior of the `Lookup` method is still up for grabs.

But how about this?
{'fraction_non_alphanumeric': 0.09456703133691823, 'fraction_numerical': 0.0022251066196921935, 'mean_word_length': 3.2640316205533595, 'pattern_counts': {'":': 0, '<': 39, '<?xml version=': 0, '>': 39, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3762445', 'n_tokens_mistral': 1547, 'n_tokens_neox': 1465, 'n_words': 746}