Maybe: nil protection for nested structs

danielberkompas

I have a problem. It’s very common to have nested structs when you deal with Ecto and associations. For example, a Person can have a City, which has a name.

The problem is, city can sometimes be nil. In that case, this code will raise an error. (“nil doesn’t respond to :name”) I want something like Ruby try here.

person.try(:city).try(:name)

Elixir has a built-in thing like this, called get_in:

get_in map, [:nonexistent, :keys]
# => nil

However, it only works with maps, not structs. The documentation says it’s specifically _not_ supposed to work with structs.

So, I have a proposal. We make a module with a functional API like this:

maybe(person, [:city, :name])

And a macro to pretty things up a bit:

maybe(person.city.name)

If any element in the chain returns nil, the expression returns nil.

Here’s my sample implementation:

defmodule Maybe do
  defmacro maybe(ast) do
    [variable|keys] = extract_keys(ast)

    quote do
      maybe(var!(unquote(variable)), unquote(keys))
    end
  end

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

  defp extract_keys(ast, keys \\ [])
  defp extract_keys([], keys), do: keys
  defp extract_keys({{:., _, args}, _, _}, keys) do
    extract_keys(args, keys)
  end
  defp extract_keys([{{:., _, args}, _, _}|t], keys) do
    keys = keys ++ extract_keys(args)
    extract_keys(t, keys)
  end
  defp extract_keys([{:., _, args}|t], keys) do
    keys = keys ++ extract_keys(args)
    extract_keys(t, keys)
  end
  defp extract_keys([key|t], keys) do
    keys = keys ++ [key]
    extract_keys(t, keys)
  end
end

And example usage:

import Maybe

defmodule Person do
  defstruct city: nil
end
	
defmodule City do
  defstruct name: nil
end
	
person = %Person{city: %City{name: "Portland"}}
maybe(person.city.name) # => "Portland"
maybe(person.nonexistent.name) # => nil

Is this a good idea? Should it be named something else? Is there something in the standard library that I missed?

17 comments

#structs

7 9081 17

2022-02-05 13:32:26 UTC

Most Liked

Show Best Posts
Show All (oldest first)
Show All (newest first)

josevalim

Creator of Elixir

Is there a certain reason why pattern matching on %{} and is treatened differently?

They are different structures. Maps were designed to always map on a subset, therefore the empty map ends up matching all maps. Otherwise, imagine how useless pattern matching on maps would be if every time I wanted to take a key from the map, I had to match on all keys. The cases where I would want to do a full matching are rather rare (and can always be achieved with map_size).

Post #3

danielberkompas

@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

Post #8

josevalim

Creator of Elixir

Remember you can use pattern matching:

case person do
  %{city: %{name: name}} -> name
  %{} -> default
end

Post #1

Last Post!

tomekowal

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