I think that optionals, like maybe should have a very good reason.
Usually it’s either there or not. There is no maybe.
So I would rather return nil, which represents that a value is not there.
Something like:
Access.at(0) |> Access.maybe
looks quite awkward.
Just my two cents,
Manfred
> Am 28.01.2020 um 19:45 schrieb José Valim <jose.va...@dashbit.co>:
>
> 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/C0B28696-D4DD-4AC9-B4D1-EAC6B6A1FDE4%40me.com.
