On Saturday, 29 February 2020 at 15:23:02 UTC, Sebastiaan Koppe
wrote:
Like I said, I don't use optionals when I care about errors.
That is not what they are designed for.
If I want to type-guard potential errors I will use SumType!(T,
Error). It forces you to handle both cases, either at compile
time (with the match template), or at runtime (with the
tryMatch template).
The power of optionals, however, lies in the following:
```
list.first.doSomething();
```
Here doSomething will only be called when the list contains at
least one item. Here I don't care about cases where the list is
empty, I just want to doSomething if it isn't.
I feel as though that's it's greatest weakness. It makes the
check whether there is or isn't a value hidden. The case when
there isn't a value should be handled explicitly, not implicitly.
Propogating a None value isn't useful and is computationally
demanding as each subsequent call will need to do a check to see
if it has a value as it results in an optional type (for binary
operators). So something like `a + b * c` is now much more
expensive than it appears. This is exactly the kind of abuse of
operator overloading that the feature is shunned for.
Anyways not sure what you mean here with the code below. If
"first" here returns an optional type, you can't call
"doSomething" like that without first checking if the value
exists. Optional just doesn't allow it and Nullable will throw an
exception.
```
list.first.doSomething(); // error
```
Which makes it odd that it forwards operator overloading to the
underlying type, which is basically just syntactic sugar for
calling a method on the object. Seems like a conflicting design
decision to me.
