I understand that this is possible, and thank you for the suggestion but
I'm not the biggest fan of anonymous functions.
When I go back and read programs written this way I can't tell if I wrote
the code or a cat walked on my keyboard.
On Tuesday, April 16, 2019 at 6:54:16 PM UTC-4, Ryan Winchester wrote:
>
> Yeah, sorry
>
> value |> (&{:ok, &1}).()
>
> On April 16, 2019 at 3:51:28 PM, Ryan Winchester ([email protected]
> <javascript:> ) wrote:
>
> value |> (&{&1}).() |> Tuple.insert_at(0, :ok)
>
> On April 16, 2019 at 3:47:58 PM, [email protected] <javascript:> (
> [email protected] <javascript:> ) 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] <javascript:> .
> 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/721abcf1-0cfd-4824-b54a-ff2aa22487f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.