The point of returning gap or ambiguous is exactly that they may or may not
be errors and it is up to you to handle them. For example, some application
may choose to surface those to the user and ask more information to resolve
the ambiguity. In a statically typed language would have to handle those as
well.
The “with” special form provides all flexibility to handle those cases
without tying the ecosystem to a shape which may not be sufficient.
On Thu, Mar 30, 2023 at 06:21 Rafael Willians Moraes <m...@rwillians.com>
wrote:
> 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
> <https://groups.google.com/d/msgid/elixir-lang-core/c839c36e-300d-4ba0-b460-8427121b600fn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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/CAGnRm4LiSfOjOgkAWn07SLTn8j-dN8Pv4vJaH7f05%2B%3D0RN6tPg%40mail.gmail.com.
