My concern is that adding List.append/2 would send the wrong signal, since
it has the wrong performance characteristics.
It is a pattern that people coming from an imperative need to unlearn so we
shouldn't make it more convenient.
We also just deprecated
<https://hexdocs.pm/elixir/changelog.html#4-hard-deprecations>
Tuple.append/2.
While List.prepend/2 doesn't suffer this issue, I'm not sure the
pipe-ability alone is enough to justify it, esp. since there is a
first-class syntax for prepending: [h | t].
It feels to me that then/2 gives us the ability to use it with the pipe if
we want to, with the flexibility of choosing what the first argument is:
... |> then(&[elem | &1])
... |> then(&[&1 | list])
Le sam. 17 mai 2025 à 07:24, Almir Neto <almir.as.net...@gmail.com> a
écrit :
> Today, if you want to pipe an append or a prepend, you must use then/2 to
> achieve this. This can be useful if the first elements of a list must be
> inserted in order through a pipe. Let me show an example:
>
> dto.ledger.accounts
> |> Enum.reject(fn %{account_number: acc_number} ->
> acc_number in [debit_acc_number, credit_acc_number]
> end)
> |> then(fn accounts -> [get_ordered_debit_accounts() | accounts])
> |> then(fn accounts -> [get_ordered_credit_accounts() | accounts] end)
> |> then(fn accounts -> accounts ++ retrieve_unordered_accounts() end)
> |> then(&Map.replace(dto.ledger, :accounts, &1))
>
> Obviously, that one is too simple and can be done in one line without
> losing too much readability, like this:
>
> dto.ledger.accounts
> |> Enum.reject(fn %{account_number: acc_number} ->
> acc_number in [debit_acc_number, credit_acc_number]
> end)
> |> then(fn accounts -> [get_ordered_debit_accounts(),
> get_ordered_credit_accounts() | accounts])
> |> Kernel.++(retrieve_unordered_accounts())
> |> then(&Map.replace(dto.ledger, :accounts, &1))
>
> But it could be cleaner if it could just do this:
>
> dto.ledger.accounts
> |> Enum.reject(fn %{account_number: acc_number} ->
> acc_number in [debit_acc_number, credit_acc_number]
> end)
> |> List.prepend(get_ordered_debit_accounts())
> |> List.prepend(get_ordered_credit_accounts())
> |> List.append(retrieve_unordered_accounts())
> |> then(&Map.replace(dto.ledger, :accounts, &1))
>
> So I think that the implementation of this can just perform a "remap" of
> the ++ operator and the [e | list] expression.
>
> def append(list, element) when is_list(list), do: list ++ [element]
> def prepend(list, element) when is_list(list), do: [element | list]
>
>
> This feature is more of a syntactic sugar than something innovative; it
> would be a way to keep the code more vertical and easier to read for some.
>
> *I will be glad to send a PR.*
>
>
> --
> 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 visit
> https://groups.google.com/d/msgid/elixir-lang-core/ed3ccb00-5069-4b66-9d6f-132eadc7ea90n%40googlegroups.com
> <https://groups.google.com/d/msgid/elixir-lang-core/ed3ccb00-5069-4b66-9d6f-132eadc7ea90n%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 visit
https://groups.google.com/d/msgid/elixir-lang-core/CANnyohYHqMAEvwxoahfuG6XixYM1e3cZxa%2B%2BvVND9r_1Wj0ERQ%40mail.gmail.com.
