Replies inline > On Feb 9, 2020, at 2:01 AM, José Valim <jose.va...@dashbit.co> wrote: > > so even in terms of inconsistency I am more inclined to think get_in should > always fail on nil and not the opposite.
I agree that is an improvement over the current implementation. But that means the shortcut of supplying a key name should be wrapped with Access.fetch!/2, not Access.get/2 (which is a breaking change). And it leaves one corner case with Access.at/2 that I'm not fond of -- it cannot distinguish between `[]` and `[nil]`. If you ask for any element out of a zero length list, the assertive thing to do is raise. > On Feb 9, 2020, at 8:30 AM, José Valim <jose.va...@dashbit.co> wrote: > > I am not sure it should be a property of the parent function. We *could* have > both operations of traversal mixed: > > get_in(data, [:key, Access.at!(0), :other_key, Access.at(0), :final_key]) > > This would provide granular control over which paths are strict, which ones > are not, which is more flexible than saying it is all strict or all lax. Yes. I have been thinking of something like `Access.nth/1` and `Access.nth!/1` as a "replacement" for `at` with new nil-handling behavior. This would allow for those mixed cases. However it makes fully strict not very natural. It pushes understanding of the subtleties to every developer. Example fully strict: get_in(data, [Access.key!(:key), Access.nth!(0), Access.key!(:other_key), Access.nth!(0), Access.key!(:final_key])) Example fully lax: get_in(data, [:key, Access.nth(0), :other_key, Access.nth(0), :final_key]) -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/ED97D643-3F63-4FE2-98E7-BF21F1F6735B%40gmail.com.
