I think it'd be a very weak link between the `if:` option or a `then_if` and the idiom of the actual `if`, especially since this is almost exclusively used in a pipe context. As for the overriding the default value: I think it's a much lower probability of this happening, and I don't think the possibility of someone wanting to extend the API in the future is a good argument for not adding to APIs now: I could argue implementing this extension will make it convenient enough that the chances of someone wanting to extend it again in the future are smaller.
Either way, I think the only way to decide on this is based on personal opinion about what the code looks like with vs. without it, and my opinion is not the popular one, so let's call it :) If anything changes, I'll reopen the discussion. Thanks everyone for the inputs! Em ter., 6 de ago. de 2024 às 13:54, Christopher Keele < christheke...@gmail.com> escreveu: > I agree with Greg here, this is clearer: > > x |> then(&if(pred(&1), do: f(&1), else: &1)) > > > your suggestion only implies what happens if `pred` is falsy while mine > is clear. > > The appeal of the proposed mechanism is its terseness, which mostly comes > from this implicit *else*. My three points against: > > - I'm a fan of explicitness in general in the core language. > - We *already* have an idiom for what implicit *else*s return in the > language—and that's *nil*, not *&1*. This mechanism violates that > expectation. > - Additionally, eventually someone will want to override the default with > a custom *else: &capture/1* clause, at which point we're right back to > capturing *if* but using three anonymous functions instead of one. > > On Saturday, August 3, 2024 at 5:09:10 PM UTC-5 gva...@gmail.com wrote: > >> You can already capture the `if` and do it as a one-liner >> >> x |> then(&if(pred(&1), do: f(&1), else: &1)) >> >> so you don't gain much yet add more complexity. Additionally, your >> suggestion only implies what happens if `pred` is falsy while mine is >> clear. >> >> -Greg Vaughn >> >> > On Aug 3, 2024, at 4:16 PM, Caio Oliveira <cai...@gmail.com> wrote: >> > >> > x >> > |> then(fn val -> >> > if pred(&1) do >> > f(val) >> > else >> > val >> > end) >> > >> > Into this: >> > >> > x |> then(&f/1, if: &pred/1) >> >> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "elixir-lang-core" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/elixir-lang-core/uM_M-DWh42A/unsubscribe > . > To unsubscribe from this group and all its topics, 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/fe354ed6-399c-4d24-931b-69f212530204n%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/fe354ed6-399c-4d24-931b-69f212530204n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAJLj4H-5O5hTaTqAi%3D7BHCT_SMAnszEG%2BPKLf6du69FEeJ0vPw%40mail.gmail.com.
