Maybe: nil protection for nested structs

I am not sure ? operator exactly fits the current feature set.
There is multiple semantics at play here:

For maps when the key is missing we get a runtime error KeyError.

For structs when the key is missing we get a compile-time error (great for preventing typos)

Elixir can track even nested structs but we need the information about them in the source code. That means it is impossible to create a macro that allows accessing nested struct and preventing typos at the same time. E.g. nothing stops you from populating person.city with a string instead of city struct.

We could resign from “typo safety” and do the checks at runtime but then we have next choice:

• do we throw KeyError when key is missing?
• or do we return nil?

I’d say KeyError is better because we are talking about structs and they populate all keys by default with nils.

Accessing nested values is very much Maybe monad. So if we want to have an infix operator for nested access I’d use >>> that stands for bind in GitHub - witchcrafters/witchcraft: Monads and other dark magic for Elixir · GitHub

  def nil >>> _, do: nil
  def struct >>> atom when is_struct(struct) and is_atom(atom), do: Map.fetch!(struct, atom)

and a full example of all the things I talked about:

defmodule Outer do
  defstruct [:inner]
end

defmodule Inner do
  defstruct [:a]
end

defmodule NestedAccess do
  def nil >>> _, do: nil
  def struct >>> atom when is_struct(struct) and is_atom(atom), do: Map.fetch!(struct, atom)
end

defmodule SafeStructs do
  def test do
    empty = %Outer{
      inner: nil
    }

    full = %Outer{
      inner: %Inner{
        a: "a"
      }
    }

    # dot nation protects from typos
    IO.inspect empty.inner
    # nil

    #IO.inspect empty.lol
    # does not compile

    IO.inspect full.inner.a
    # "a"

    # pattern matching without structs does not protect from typos
    case empty do
      %{inner: %{a: a}} -> a
      %{} -> nil
    end
    |> IO.inspect
    # nil

    case empty do
      # note the non existent foo key
      %{foo: %{a: a}} -> a
      %{} -> nil
    end
    |> IO.inspect
    # nil

    # pattern matching with structs protects from typos
    # because it gives compiler enough information
    case empty do
      %Outer{inner: %Inner{a: a}} -> a
      %Outer{} -> nil
    end
    |> IO.inspect
    # nil

    #case empty do
    #  %Outer{foo: %{a: a}} -> a
    #  %Outer{} -> nil
    #end
    #|> IO.inspect
    # does not compile

    import NestedAccess
    empty >>> :inner
    full >>> :inner >>> :a
  end
end

To sum up: you can solve the problem with a two-line function defining an infix operator. Just be careful to think about the semantics of missing keys. For structs missing a key is definitely a typo. For maps, you could add a case like:

def map >>> atom when is_map(map) and is_atom(atom), do: Map.get(map, atom)

because missing keys might be a legitimate thing.

And yet another question is: what if the city is suddenly a string instead of a struct? Do you return that string or throw an error? I think it is best to leave that decision to people implementing actual business logic and leave it out of the language

I really wish this were the case. Kotlin provides this out of the box, and it’s super convenient.

person?.city?.name

Kotlin uses this ? syntax for a lot of other things concerning nulls, which don’t necessarily apply to Elixir, but I think if it worked for structs, it would be a really nice convenience.

Well, I for one just came into need of this today. Given how clever a language Elixir is, I’m actually surprised there isn’t a feature like this already

Syntax wise I wonder if ? (in place of .) could work.

person?city?name

That reads pretty well to me.

[Update]

I ended doing this, e.g. (person.city || %{name: ""}).name. Which is okay for one level, but still rather ugly for more, e.g. ((person || %{city: nil}).city || %{name: ""}).name.

I ran into a similar issue where I had lots of structs that were basically wrappers for maps, where I just wanted the compile time guarantee of the structs. I wrote a small using macro that I can add to the top of a struct and then use it with the Access module

defmacro __using__(_) do
    quote do
      @behaviour Access

      defdelegate fetch(term, key), to: Map
      defdelegate get(term, key, default), to: Map
      defdelegate get_and_update(term, key, fun), to: Map
      defdelegate pop(date, key), to: Map
    end
  end

To be frank I don’t know. Now it doesn’t work. So I must have done something differently and can no longer reproduce it

UPDATE:
The thing that works for my case is something like:

row = MyApplication.MyContext.MyModel |> MyApplication.Repo.one()
column_value = if is_nil(row), do: nil, else: row.column

Yet I am surely not happy with how it looks. OTOH get_in(row, [:column]) works nicely when row is nil but fails when it is not. get_in(row, [Access.key(:column)]) does the opposite. It works when row is not nil, but fails when it is. And I didn’t come up with a more elegant one-liner to cover both cases. And this doesn’t even touch nested structures/associations.

This makes me wonder.. is there really no need for something like an equivalent of Rails’ try in Elixir/Phoenix? Sure I could probably implement something like that somewhere in every project, but that kind of “safe traversal” does look like a very common case to me. At least coming from the Rails (and a few other languages/frameworks) world.

Hmmm…

For me I can not use get_in on an arbitrary struct…

iex(1)> defmodule S do
...(1)>   defstruct [:a, :b]
...(1)> end
iex(2)> get_in(%S{}, [:a])
** (UndefinedFunctionError) function S.fetch/2 is undefined (S does not implement the Access behaviour)
    S.fetch(%S{a: nil, b: nil}, :a)
    (elixir 1.11.4) lib/access.ex:286: Access.get/3

What have you done?

What I actually need is a “safe navigation” through Phoenix “models”, exactly the case brought on the very beginning of this thread. A quick test shows the get_in to work so it looks to me that either things changed or there are some gotchas I am not aware of

If a structs module implements the Access behaviour, then you can use it with the lense like accessors.

Though a 1:1 mapping to struct keys is often not really what you want for structs. Eg. for a set you might have a couple of struct keys required for the implementation, but each on its own doesn’t have any value. Instead you use Access behaviour to make a lookup in the set and either return nil for inexisting items or the item itself if it is in the set. (This is just an example)

Is this still true as of today?

@Oliver, yes, Map.get does do what I want. I actually use it here to provide the functional API for Maybe:

def maybe(nil, _keys), do: nil
def maybe(val, []), do: val
def maybe(map, [h|t]) do
  maybe(Map.get(map, h), t)
end

You can call it like so: maybe(map, [:first, :second, :third]). I think it’s a little more convenient than doing a pipeline.

The maybe macro just converts calls like this: maybe(map.first.second.third) into functional calls for maybe(may, [:first, :second, :third]).

Edit: Since the Maybe module is so small, I decided not to release a hex package for it. If you’re interested, you can find it here: Add Maybe by danielberkompas · Pull Request #14 · infinitered/phoenix_base · GitHub