I'm in favor of them being nilsafe by default.
Allen Madsen
http://www.allenmadsen.com
On Wed, Jan 29, 2020 at 11:24 AM Tor Bjornrud <bjorn...@gmail.com> wrote:
> I wouldn't mind having opts for something like this. Avoids creating a
> slew of Access functions that then become difficult to sift through.
>
> %{"items" => nil} |> get_in(["items", Access.at(0, nilsafe: true)
>
>
> On Tuesday, January 28, 2020 at 8:10:04 PM UTC-6, Greg Vaughn wrote:
>>
>> 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...@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 <gva...@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-l...@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-l...@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/1ae0b9d3-9471-4750-8734-281033e9a1dc%40googlegroups.com
> <https://groups.google.com/d/msgid/elixir-lang-core/1ae0b9d3-9471-4750-8734-281033e9a1dc%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 on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/CAK-y3Cu%2BGBO1RWsdAjAHoaukV3w4QJPPdqqNU_miQ_%3Dv5%3DdDeQ%40mail.gmail.com.
