I see your point.
I was thinking more along the lines of consistency in the API design. If
you can wrap an item in a list why can't you wrap it in a tuple? *If you
could wrap things in tuples* then you *could* insert a value at the front
of said tuple.This is more of an exercise in "you could" rather than "you
should".
On Tuesday, April 16, 2019 at 7:07:33 PM UTC-4, José Valim wrote:
>
> If the choice is between:
>
> value |> Tuple.wrap() |> Tuple.insert_at(0, :ok)
>
>
> and
>
> {:ok, value}
>
>
> I believe we should choose the second every time.
>
> If the choice is between:
>
> value
> |> very()
> |> long()
> |> pipeline()
> |> Tuple.wrap()
> |> Tuple.insert_at(0, :ok)
>
>
> and:
>
>
> value
> |> very()
> |> long()
> |> pipeline()
> |> OkError.ok()
>
>
> and:
>
>
> var =
> value
> |> very()
> |> long()
> |> pipeline()
>
> {:ok, var}
>
>
> I don't see any reason why we should ever do the first one.
>
> So I really don't see which problem Tuple.wrap is supposed to solve.
>
> *José Valim*
> www.plataformatec.com.br
> Skype: jv.ptec
> Founder and Director of R&D
>
>
> On Wed, Apr 17, 2019 at 12:58 AM <t...@scalpel.com <javascript:>> wrote:
>
>> 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 (
>>> he...@ryanwinchester.ca ) wrote:
>>>
>>> value |> (&{&1}).() |> Tuple.insert_at(0, :ok)
>>>
>>> On April 16, 2019 at 3:47:58 PM, t...@scalpel.com (t...@scalpel.com )
>>> 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 <t...@scalpel.com > 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 <overm...@gmail.com >
>>>>>> wrote:
>>>>>>
>>>>>>> On Tuesday, April 16, 2019 at 3:04:13 PM UTC-6, t...@scalpel.com
>>>>>>> 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 elixir-l...@googlegroups.com .
>>>>>>> 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 elixir-l...@googlegroups.com .
>>> 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 elixir-l...@googlegroups.com <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/elixir-lang-core/721abcf1-0cfd-4824-b54a-ff2aa22487f3%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/elixir-lang-core/721abcf1-0cfd-4824-b54a-ff2aa22487f3%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 elixir-lang-core+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/5607dc54-2c5d-452c-a5a5-fa6ec03864c3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
