value |> (&{&1}).() |> Tuple.insert_at(0, :ok)
On April 16, 2019 at 3:47:58 PM, [email protected] ([email protected] ) wrote:
Fair enough, I know when to give up on a losing battle.
Would you consider an alternative like Tuple.wrap/1. It would work exactly
like List.wrap/1 but doesn't carry the baggage that "error" and "ok" would
have. This way I could still accomplish the goal of keeping pipe chains
clean with something like.
value |> Tuple.wrap() |> Tuple.insert_at(0, :ok)
Which is a bit wordier but functionally equivalent to the original proposal.
On Tuesday, April 16, 2019 at 6:04:55 PM UTC-4, José Valim wrote:
>
> Hi Tom,
>
> You don't have to buy the arguments, we can agree to disagree, but they
> are still the reason for not adding such functions to Elixir. :)
>
> I also agree with is_even and is_odd being similar convenience functions
> but they do have a rationale. They were added before defguard existed. At
> the time, writing guards was a bit more bureaucratic. But if is_odd/is_even
> were proposed today, they would most likely have been rejected as well.
>
> Elixir already has a perfectly fine syntax via curly brackets for creating
> ok and error tuples, that also works on matching, so my recommendation is
> still to build an extra vocabulary in your app or as a separate library.
>
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R&D
>
>
> On Tue, Apr 16, 2019 at 11:46 PM <[email protected] > wrote:
>
>> I disagree that this should be a library. (I've already done this in my
>> app and would be fine extracting it into one though) I don't buy the
>> slippery slope argument. The functions are very simple to create and
>> maintain, and it's not like the Tuple module is overflowing with
>> complexity. We have things like 'is_even' and 'is_odd' because they are
>> common to work with. :ok and :error are insanely common in elixir
>> codebases. Why not add convenience methods?
>>
>> On Tuesday, April 16, 2019 at 5:22:38 PM UTC-4, José Valim wrote:
>>>
>>> Hi Tom, thanks for the proposal.
>>>
>>> As OvermindDL1 already hinted, this can lead to a slippery slope where
>>> we need to add bang variants, question mark variants, ok/1/2/3/4 to deal
>>> with arities and so on. I would suggest building this vocabulary as
>>> necessary in your applications or, if you want to share it with the world,
>>> it could be a nice library. Hint: the package ok_error seems to be
>>> available. :)
>>>
>>> *José Valim*
>>> www.plataformatec.com.br
>>> Skype: jv.ptec
>>> Founder and Director of R&D
>>>
>>>
>>> On Tue, Apr 16, 2019 at 11:12 PM OvermindDL1 <[email protected] >
>>> wrote:
>>>
>>>> On Tuesday, April 16, 2019 at 3:04:13 PM UTC-6, [email protected] wrote:
>>>>>
>>>>> It is often the case that you want to wrap the result of an operation
>>>>> in an ":ok" or ":error" Tuple. We should add convenience wrapper functions
>>>>> since this is so common and it cleans up otherwise ugly code.
>>>>>
>>>>> def ok(value), do: {:ok, value}
>>>>> def error(value), do: {:error, value}
>>>>>
>>>>
>>>> This could be quite useful! On the other side it would be useful to
>>>> add functions like these as well:
>>>>
>>>> def ok!({:ok, value}), do: value
>>>>
>>>> def ok?({:ok, _value}), do: true
>>>> def ok?(_), do: false
>>>>
>>>> And so forth for error as well. They are not really useful on their
>>>> own because matching is better, but for use in pipes that would be quite
>>>> useful (right now I use the exceptional library, which does similar things
>>>> and more).
>>>> --
>>>> 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 [email protected] .
>>>> To view this discussion on the web visit https://groups.google.com/d/
>>>> msgid/elixir-lang-core/ 30614530-7e33-4cb8-bffb-
>>>> 63c18248d340%40googlegroups. com
>>>> <https://groups.google.com/d/msgid/elixir-lang-core/30614530-7e33-4cb8-bffb-63c18248d340%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>> For more options, visit https://groups.google.com/d/ optout
>>>> <https://groups.google.com/d/optout> .
>>>>
>>> --
>> 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-l...@ googlegroups.com .
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/elixir-lang-core/ 0314757d-eff2-4b23-8130-
>> a19ee921b254%40googlegroups. com
>> <https://groups.google.com/d/msgid/elixir-lang-core/0314757d-eff2-4b23-8130-a19ee921b254%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/ optout
>> <https://groups.google.com/d/optout> .
>>
> --
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 [email protected] .
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/2e7204c7-6d06-49f9-8edc-7c631f75063a%40googlegroups.com
<https://groups.google.com/d/msgid/elixir-lang-core/2e7204c7-6d06-49f9-8edc-7c631f75063a%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout .
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/CAKBKqKSQOCTWfwkECGwsfST8iFFLYS4y-56fBxg27oxezSpt%2BA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
