Maybe.Some(null) does not throw and has a different behavior than Maybe.None()

I’m currently testing SuccincT, quite happily so far, but encountered a problem when trying to integrate it in a part of a project I’m working on. Why is Maybe<string>.Some(null) allowed ?

var someNull = Maybe<string>.Some(null);

in this case, someValue.HasValue returns true and someNull.Value returns null, where I would have expected this to behave the way Maybe<string>.None() does (after all, it’s seems to be the same thing semantically speaking), or at least to throw.

Of course this is not senseless, but in my mind it defeats the objective of Maybe, which is to provide a way of avoiding nulls. That means that if a legacy part of the project passes an unchecked value which turns to be null, Maybe will happily live with it, propagating it without complaining, meaning that I still need to rely on defensive code even in a Maybe enabled codebase.

Is there a reason I don’t get behind this behavior ?

If not, which behavior would you recommend / prefer ?

[DavidArno]

The following was implemented in v4:

Assigning null to Some will throw, An implicit cast from null to an option will result in a none, Option<RefType>.None == null.

Closing as implemented.

[DavidArno]

Well it turns out that the changes I’m making for v4 effectively force my hand here. I’ve never been happy with having Option<T> and Maybe<T>, so the latter is going and the former is becoming a struct. To make that play nicely with null:

1. Assigning null to Some will throw,
2. An implicit cast from null to an option will result in a none,
3. Option<RefType>.None == null.