Idiomatic way to express errors without resorting to exceptions

[Arine]

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.