Well, the difference is really in their usage. Tuples are rarely used dynamically, you usually want to see tuples as literals in your code. The Tuple docs also mention it:
> The functions in this module that add and remove elements from tuples are > rarely used in practice, as they typically imply tuples are being used as > collections. To append to a tuple, it is preferable to use pattern matching *José Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R&D On Wed, Apr 17, 2019 at 1:20 AM <[email protected]> wrote: > 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 <[email protected]> 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 ( >>>> [email protected] ) wrote: >>>> >>>> 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/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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/5607dc54-2c5d-452c-a5a5-fa6ec03864c3%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/5607dc54-2c5d-452c-a5a5-fa6ec03864c3%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/CAGnRm4JFm9mD0EEkdiXFajUZik7tvKa1i35%3DsOUAa4SpjtO6Jg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
