Update: we also have precedents on this behaviour: pop_in also aborts as soon as it sees a nil.
*José Valimhttps://dashbit.co/ <https://dashbit.co/>* On Fri, Apr 2, 2021 at 6:41 PM José Valim <[email protected]> wrote: > After coming to this issue a couple times, I believe we should accept this > proposal. > > My arguments were: > > 1. This proposal won't work for update_in/pop_in. My counter-argument, as > of now, is that this is already true given that get_in(nil[:foo][:bar]) > returns nil but update_in(nil[:foo][:bar], & &1) raises. > > 2. This proposal would remove an API that raises on nil. My counter > argument, as of now, is that if you don't want to raise on nils, you likely > won't use get_in anyway. Instead you will do map["foo"]["bar"] |> Enum.map. > > I plan to submit this to master soon, to be included on v1.13. > > On Monday, July 6, 2020 at 5:46:31 PM UTC+2 [email protected] wrote: > >> I have not thought about this in a while. I don't immediately see those >> new functions as something I'd use. They push extra burden on the client >> programmer to know all the corner cases and protect from them. I always >> envisioned `get_in` as something like searching an html document via a css >> selector. It never raises, even if the document is empty. It either finds >> matching nodes or it does not. >> >> I learned from earlier in this thread that is not the mental model the >> core team has for `get_in`. I ended up creating a small library to meet my >> needs (https://hex.pm/packages/path_express). >> >> -Greg >> >> > On Jul 6, 2020, at 5:54 AM, José Valim <[email protected]> wrote: >> > >> > Resurrecting this old-thread. Greg, what if we had a Access.if_nil([]) >> that would put an empty list if there is a nil value? We could also have >> Access.on_nil(:error), which effectively halts. >> > >> > A bit verbose but it will give you control exactly what to do and when, >> without coupling to the current functions. >> > >> > -- >> > 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/36580c49-f276-4512-a2aa-da7ecb7daf60o%40googlegroups.com. >> >> >> -- > 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/4389ddde-4aff-4002-b5a6-bd519d693065n%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/4389ddde-4aff-4002-b5a6-bd519d693065n%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4L-BomURgSyb0%2B0EX3ExX%2BQxfi46ibB8X6TvXxVwJx%3DFw%40mail.gmail.com.
