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
```
On Saturday, March 3, 2018 at 8:31:54 PM UTC-3 yordis...@gmail.com wrote:
> Ben it is not about the boilerplace and less typing or more typing,
>
> but I found myself having a hard time parsing those | for reading
> different types, because of that, having something like this, when you
> brain sees this automatically understands
> what is that type about, the parsing becomes easier.
>
> Also from language perspective, I like to embrace this as type, like
> Haskell or Swift those with those Optional types (I dont need a optional
> type itself on elixir btw, just the typespec)
>
> but, that is just me, I can't speak for others.
>
>
> On Tuesday, February 27, 2018 at 4:11:39 AM UTC-8, Yordis Prieto wrote:
>
>> Introducing `maybe(t)` it will reduce the boilerplate code for `nil |
>> something`
>>
>> It is more convenience to write it this way, at least for me.
>>
>> What are your thoughts about it?
>>
>
--
You received this message because you are subscribed to the Google Groups
"elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/c839c36e-300d-4ba0-b460-8427121b600fn%40googlegroups.com.
