I agree
Although one could simple define their own `@type result(t) :: {:ok, t} | {:error, term}`, having this built-it IMO would be great for the ecosystem.
Maybe biggest problem with :ok|:error tuples right now is that lib (including standard Elixir libs) are inconsistent on that from. Therefore, having this type built-in could be a way of encourage people to use it throughout the ecosystem.
Take returns from modules
DateTime and
Integer for example:
- `DateTime.convert/2`
```
{:ok, t}
| {:error, :incompatible_calendars}
``` - `DateTime.from_naive/1` returns
```
{:ok, t}
| {:ambiguous, first_datetime :: t, second_datetime :: t}
| {:gap, t, t}
| {:error, :incompatible_calendars | :time_zone_not_found | :utc_only_time_zone_database}
``` - `DateTime.from_iso8601/1`
```
{:ok, t, Calendar.utc_offset}
| {:error, atom}
```
- `Integer.parse/1`
```
{integer, remainder_of_binary :: binary}
| :error
```
If one just wants to assert if the result is a success or failure, they have to know implementation detail of the given result value (not to mention that I'm not even sure if those `ambiguous` and `gap` from `from_naive` are success or failure).
Therefore, IMO, having a result type is a starting point to have some consistency across the ecosystem.
I'd suggest the following types
```
@type result(t, s) :: {:ok, t} | {:error, s}
@type result(t) :: {:ok, t} | :error
```