Elixir version of a safe navigation operator? (navigating nil in maps/structs)

user[:address][:city]

# or

user.address[:city]

I don’t know what your use case is, but an if might be more idiomatic and expressive. Otherwise, you can use one of the above.

Oh, right! I forgot and I could also use Kernel.get_in/2

I spoke too soon as both your examples would raise an UndefinedFunctionError returning User does not implement the Access Behaviour.

However, I believe the current best alternative is: user |> Map.get(:address) |> Map.get(:city), but if I import Map, only: [:get], then it becomes user |> get(:address) |> get(:city)

You can add @derive [Access] to your User and Address struct/schema modules to fix this.

However, I would recommend defining a named function to accomplish your needs instead.

defmodule User do
  def city(%{address: nil}), do: nil
  def city(%{address: address}), do: address.city
end

Doesn’t work either: (ArgumentError) Access is not a protocol, cannot derive Access for User. However, I agree that it’s probably better to use a named function and likely the more idiomatic solution I’m looking for…

Whoops, sorry. Looks like that was changed long ago.

Hmm. I probably should’ve searched earlier, but @danielberkompas asked this last year: Maybe: nil protection for nested structs - #7 by Qqwy and he even created a small module that is a nod to the Maybe monad in Haskell?

Additional context for why deriving Access doesn’t work: Get rid of the Access protocol · Issue #2973 · elixir-lang/elixir · GitHub

If you want something library-less and simple then you could just use with:

iex(46)> blah = %{vwoop: nil}
%{vwoop: nil}
iex(47)> with\
...(47)>   %{vwoop: vwoop} <- blah,
...(47)>   %{vreep: vreep} <- vwoop do
...(47)>   vreep+4
...(47)> else nil end
nil

An aside:
I really wish with was just a macro and not a special form and that it put everything in the do like:

with do
  %{vwoop: vwoop} <- blah
  %{vreep: vreep} <- vwoop
  vroop when vroop > 12 <- vreep + 4
  {:ok, vroop}
else
  :error
end

It would be so much easier to use with no weird spacing stuff and trailing comma’s that is inconsistent with most matcher cases and such… >.>

Consequently there is a fixed version in a library.

Yeah, I actually first thought about using with special form but it’s too verbose for me, especially in template code.

Ah, yes! I wish it were a macro, too. Has this suggestion ever been brought up in the mailing list?