Hi Greg, I have been thinking more about this too, and I think there are
some neat ways we can make this more accessible:
We could introduce Access.nillable (please suggest a better name) that you
would use like this:
get_in(root, Access.nillable([:foo, :bar, Access.at(0)]))
Basically, it
I just wanted to follow up and summarize here. I submitted a PR
https://github.com/elixir-lang/elixir/pull/9773 with some more discussion, but
the core point there was that we needed more discussion on the core list before
a PR and it was closed. Nil-safety by default is undesirable in more
> What I find curious is that once we implement Kernel.nillable_get_in, why
would anyone choose to use Kernel.get_in instead?
When I don't expect anything to be nil, I want it to fail as soon as
possible, instead of having nil further creeping into the system.
Personally, most of the times I used
Hi José, I have considered that as one possibility too. From Eric's comments I
don't belive the Access module is the correct place to implement it though.
Personally, I don't care what the module is called because I am prepared to
create my own module to handle this.
What I find curious is
One more point. Even if my proposal is not accepted, these docs for
Kernel.get_in really need to change
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,
I recognize more use cases than mine. Given we will not change Kernel.get_in, I
have ideas for other, less "nillable" names, such as "get_path" or "path_in" to
make mil-safety less of an exceptional situation. Path expressions, as
originally used in object oriented databases, typically did not
For now, I don't think we should add a new function to Kernel. So we should
find something that makes a path nillable for definition in Access, and
then you can define get_path in your app if that's what you prefer.
On Sat, Feb 8, 2020 at 2:23 AM Greg Vaughn wrote:
> I recognize more use cases
