Add get_in/1 with safe nil-handling for access and structs

[josevalim]

No description provided.

[wojtekmach]

it's probably redundant but I'd consider adding:

Suggested change

	end
	assert_raise KeyError, ~r"key :unknown not found", fn -> get_in(users.meg.unknown) end
	end

[srcrip]

@josevalim, would it be feasible to add list handling too if these kinds of changes are on the table? I've been doing something like this a little bit as a utility:

  defmodule Utils do
    def get(data, keys)
    def get(data, [h]) when is_function(h), do: h.(:get, data, & &1)
    def get(data, [h | t]) when is_function(h), do: h.(:get, data, &get(&1, t))
    def get(nil, [_]), do: nil
    def get(nil, [_ | t]), do: get(nil, t)

    # list part
    def get(data, [h]) when is_list(data) and is_integer(h), do: Enum.at(data, h)
    def get(data, [h | t]) when is_list(data) and is_integer(h), do: get(Enum.at(data, h), t)

    def get(data, [h]), do: Access.get(data, h)
    def get(data, [h | t]), do: get(Access.get(data, h), t)
  end

[josevalim]

It has been discussed a couple times. Doing list[i] would promote linear access and it is very easy to shoot yourself in the foot. Especially by doing things like put_in list[i], value under a loop. I'd try to find the previous discussions.

We have discussed subset operators, inspired by JSONPath, such as get_in(posts[..].comments[..].author.name) (get the name of all comment authors from all posts) but it comes with other downsides. Definitely a separate convo.

[srcrip]

I think putting such access would make the most sense in a helper like get_in though, not dedicated syntax.

Consider the scenario of a user trying to use get_in with a map that contains nested lists. They'll end up decomposing it into a pipeline that calls Enum.at anyways, cause that's what they wanted to do.

[josevalim]

@srcrip that would be a departure of how *_in functions work though, since none of them change how the brackets are interpreted and rather just delegate.

Your proposed mechanism would not extensible either (because it would be hardcoded as part of get_in) and the rationale of Access is exactly to make the syntax extensible to everyone. What happens if someone wants to provide a similar behavior for, say, Nx.Tensor?

[josevalim]

Consider the scenario of a user trying to use get_in with a map that contains nested lists. They'll end up decomposing it into a pipeline that calls Enum.at anyways, cause that's what they wanted to do.

Btw, I totally hear you and I agree. However, we need to find a solution that is consistent with the rest of the language. I am not sure at the moment what that is, but let's continue exploring!

[josevalim]

💚 💙 💜 💛 ❤️