I agree that they are rarely used dynamically, but when they are they can be quite the pain to work with.
For example, if you are doing any work with ASN.1 dynamic tuples are everywhere. Any advanced work in cryptography or telecom becomes harder to work with than I would like it to be. On Tuesday, April 16, 2019 at 7:24:15 PM UTC-4, José Valim wrote: > > 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] <javascript:>> 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] <javascript:>. >> 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/50776062-e75d-4f31-8266-2b633e78bf89%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
