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.
