Only non-null values

[manuel-plavsic]

This pull requests ensures that nullable types cannot be used when working with Option or Result. Additionally, since refactoring was necessary anyway, catchOption, catchOptionAsync, catchResult and catchResultAsync were simplified so that only the value for the Some option and, respectively, the one for the Ok option must be returned.

It can be argumented that using Option with nullable types defeats its purpose. None should be used instead of using Some wrapping null. By enforcing this constraint, a lot of bugs can be prevented.

Also, consider the NI typedef below:

typedef NI = int?

void fn(NI? a) {
  final option = Option.from(a);
}

If a is null, then this could mean one of these things:

• 1. a is null because a NI object referencing null was passed (null at the NI level, not "directly" at the NI? level)
• 2. a is null because a NI? object referencing null was passed (null at the NI level)
• 3. a is null because null was explicitly passed

What Option values were expected and which ones were created?

• 1. In the first case, a Some(null) value would make sense here, given that a null NI value was passed. A None value is created instead. This is because all was passed was null and it is not possible to distinguish between NI? and NI types in this case. Even though it is valid to manually create a Some(null) value.
• 2. None is expected and created
• 3. None is created, even though it may not be clear if a was meant to be null at the NI or NI? level.

At the Result/Ok level, having a non-nullable T (i.e. T extends Object) would bring only benefits. An Option<T> type should be defined instead of a nullable T?. No longer having to decide between Option<T> and nullable type T? will result in a much more uniform style.

It is fine for E to extend Object, because:

• An instance of Null cannot be thrown anyway.
  • An Object must be thrown, which important for catchOption, catchOptionAsync, catchResult and catchResultAsync.
• Null would not be a good candidate for Err's type anyway.

In conclusion, enforcing non-nullable types removes ambiguity and prevents bugs.

[manuel-plavsic]

I have just noticed that oxidized enforces non-nullable types as well.