So (+) would be defined as adding its operands, except if one of them is an error (in which case the result would be an error).

Either is a sum type. What if I don't want that. It's not about handling errors per se, but modeling the type.

Yes, I understand. But by "implicitly" I really meant that. You don't see the type, only the compiler does. The programmer only sees the non-error part of the type (the "Right" part of Either).

How could this work? I specify an interface to an api.

C Foo(A a) = ...

Someone then provides me with some not-A error value. What should I do? What do you mean by implicit.

> Either is a sum type. What if I don't want that.

Product types work as well, if you want. But unless your return type is a monoid (or like, a semilattice maybe?) then you're going to end up with Sum Types somewhere.

The vast, vast majority of software engineers and students work with sum types every day and they're totally fine with them. Most languages implicitly sum many values with null.

Unless you're running in a multi-threaded environment or run out of memory?

These sounds like exceptions rather than errors to me. Difference being, exceptions truly are exceptional and not anticipated; like running out of memory. How do you even handle that? Would probably let it crash and restart (Erlang model). Errors is something you anticipate can happen, such as getting 4xx-5xx back from the server and know what to do in those cases.

Then it's fair to say that you definitely can't get an error by adding two numbers.

> How do you even handle that?

You request a smaller block of memory? Not everyone is always requesting the minimum they need right now.

> Would probably let it crash and restart (Erlang model)

The Erlang model is to let a partial failure trigger a less complex part of the system to resume that logic based on a strategy.

> Then it's fair to say that you definitely can't get an error by adding two numbers.

I mean, you can also accept garbage back, I guess?