Thanks, José. I agree with the need to be consistent. I will look at the bigger picture, though, like Manfred I find the addition of "maybe" to be awkward, so my preference is to have the existing recommended functions in the Access module intended for use with get_in to be consistently nil safe. I'm open to more ideas, too.
-Greg Vaughn > On Jan 28, 2020, at 12:45 PM, José Valim <jose.va...@dashbit.co> wrote: > > The proposal is reasonable however it would introduce an inconsistency since > the other selectors in Access, such as Access.key, are also not nil safe. So > whatever solution we choose needs to be consistent. > > One possible suggestion is to introduce a "Access.maybe" that composes but > composition would have to be back to front: > > %{"items" => nil} |> get_in(["items", Access.at(0) |> Access.maybe]) > > Another idea is to introduce maybe_at, maybe_key, maybe_key! and so on. But I > am not sure if this is desirable. Thoughts? > > On Tue, Jan 28, 2020 at 7:33 PM Greg Vaughn <gvau...@gmail.com> wrote: > I propose that the function returned from Access.at/1 special case nil such > that the overall Kernel.get_in/2 call returns nil instead of raising an error. > > Rationale: > I originally blamed this on Kernel.get_in/2 and I'd like to thank Eric > Meadows-Jönsson for explaining the underlying reason to me on Slack. > > I like to think of Kernel.get_in/2 as a nil-safe way of plucking values out > of nested data structures, but I learned today that is only partially > correct. The nil-safety comes from the underlying Access.get/2 calls. The > docs for get_in includes: > > In case any of the entries in the middle returns nil, nil will be returned > as per the Access module: > iex> users = %{"john" => %{age: 27}, "meg" => %{age: 23}} > iex> get_in(users, ["unknown", :age]) > nil > > and I expected use of Access.at/1 in my keys to act similarly, but it > doesn't. For example: > > iex(185)> %{"items" => ["desired_value"]} |> get_in(["items", Access.at(0)]) > "desired_value" > iex(186)> %{"items" => nil} |> get_in(["items", Access.at(0)]) > ** (RuntimeError) Access.at/1 expected a list, got: nil > (elixir) lib/access.ex:663: Access.at/4 > > I propose that the function returned from Access.at/1 special case nil such > that the overall get_in/2 call returns nil instead of raising an error. I > have not dug into the source yet but I'm happy to work up a PR if there is > interest in this change. > > -Greg Vaughn > > -- > 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/6B6AB775-F3D5-40E5-BFBD-9852FBCBD1D0%40gmail.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 elixir-lang-core+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4KZPZ5mpP6SSzhmq3jpuZBYA1irpmOa19UNH2fS_3QKQA%40mail.gmail.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 elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/EE18A208-4B1A-47D2-A2C1-F71CC1C09FAA%40gmail.com.