This was a hurdle for me when I first started coding in Elixir. Whenever I wanted to update a data structure, I'd look through the standard library for the appropriate function.
Instead of using `list1 ++ list2` I looked for `List.concat/2`. When that didn't exist I'd look for and find `Enum.concat/2`. Similarly, it rarely occurred to me to use `[elem | list]`. I instead looked for `List.prepend/2`, then `Enum.prepend/2`. When neither of those existed, I had to resort to elixirforum/slack/stackoverflow/etc to lead me to the `[elem | list]` syntax. All that to say, I'm torn on this proposal. On the one hand it could help those new to elixir get un-stuck faster. On the other hand, those same coders wouldn't be pushed to learn the `[a | b]` syntax. On Saturday, May 24, 2025 at 1:21:22 AM UTC-6 sabi...@gmail.com wrote: > 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.a...@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-co...@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/68e85d74-f457-4e98-b0fc-bbf9a3c182fcn%40googlegroups.com.
