CompileError: "invalid use of _. "_" represents a value to be ignored in a pattern and cannot be used in expressions"

This case statement is perfectly functional, but it repeats code:

case foo do
  {:pass, _} = reason ->
    Logger.info(reason)

  {:ok, _, _} ->
    status = Keyword.get(opts, :status)
    some_func(status)

    Logger.info("Executing function: #{some_func} with status: #{status}")

  {:ok, :bosh} ->
    status = Keyword.get(opts, :status)
    some_func(status)

    Logger.info("Executing function: #{some_func} with status: #{status}")
end

To eliminate repetition, the following version was attempted, however it results in a CompileError: invalid use of _. "_" represents a value to be ignored in a pattern and cannot be used in expressions

case foo do
  {:pass, _} = reason ->
    Logger.info(reason)

  message
  when message == {:ok, _, _} or message == {:ok, :bosh} ->

    status = Keyword.get(opts, :status)
    some_func(status)

    Logger.info("Executing function: #{some_func} with status: #{status}")
end

What’s the best way to resolve this issue in a case statement? What alternate control flow structure, if any, would be more appropriate for this task?

What version of Elixir are you running? Trying the code from your post in 1.12.0 produces a different compile error:

** (CompileError) main.exs:14: invalid use of _. "_" represents a value to be ignored in a pattern and cannot be used in expressions
    (stdlib 3.15.2) lists.erl:1358: :lists.mapfoldl/3
    (stdlib 3.15.2) lists.erl:1359: :lists.mapfoldl/3
    (stdlib 3.15.2) lists.erl:1358: :lists.mapfoldl/3
    (elixir 1.12.2) expanding macro: Kernel.or/2

I can get the illegal expression in guard, case is not allowed message if I use match?({:ok, _, _}, message) instead of == in the guard.

1 Like

1.12.2

I ran the original code again and received the identical CompileError you did. It appears that I got something mixed up when writing up the general version for the OP. Any thoughts on the best way to deal with the CompileError you got?

You are breaking a few rules in your code.

  1. _ matches anything on the left side of a assignment, not on the right side, where you are defining your values.
  2. _ works with the = (match) operator not with the `==’ (comparison) operator.
  3. you cannot use the = operator in guards

Anyway, There are at least two ways of doing it, one with match? as @al2o3cr mentioned, another one with guards.

foo = {:ok, :bosh}

cond do
  match?({:pass, _}, foo) ->
    1

  match?({:ok, _, _}, foo) or match?({:ok, :bosh}, foo) ->
    2
end

case foo do
  {:pass, _} ->
    1

  foo
  when is_tuple(foo) and tuple_size(foo) == 2 and elem(foo, 0) == :ok
  when is_tuple(foo) and tuple_size(foo) == 3 and elem(foo, 0) == :ok and elem(foo, 1) == :bosh ->
    2

  # previous clause can be optimized like this which can be optimized like this (not so much readable as the previous one though)
  foo
  when is_tuple(foo) and elem(foo, 0) == :ok and
         (tuple_size(foo) == 2 or (tuple_size(foo) == 3 and elem(foo, 1) == :bosh)) ->
    2
end

There is a practical use for the cumbersome second solution, and that is GUARDS! you can define the guard with defguardand use it even in function definitions (since you asked about avoiding repetition)

  defguard is_foo(term)
           when is_tuple(term) and elem(term, 0) == :ok and
                  (tuple_size(term) == 2 or (tuple_size(term) == 3 and elem(term, 1) == :bosh))

case foo do
  {:pass, _} ->
    1

  foo when is_foo(foo)  ->
    2
end

4 Likes

Maintaining the case:

run_fn = fn ->
  status = Keyword.get(opts, :status)
  some_func(status)

  Logger.info("Executing function: #{some_func} with status: #{status}")
end

case foo do
  {:pass, _} = reason ->
    Logger.info(reason)

  {:ok, _, _} ->
    run_fn.()

  {:ok, :bosh} ->
    run_fn.()
end

Using with (this one will kill you one day)

with {:pass, _} = reason <- foo do
  Logger.info(reason)
else
  _ ->
    # one day this will run for {:error, :fatal}...
    status = Keyword.get(opts, :status)
    some_func(status)

    Logger.info("Executing function: #{some_func} with status: #{status}")
end

Safer with, though Keathley may make sad noises Good and Bad Elixir

with :ok <- elem(foo, 0) do
  status = Keyword.get(opts, :status)
  some_func(status)

  Logger.info("Executing function: #{some_func} with status: #{status}")
else
  :pass ->
    Logger.info(foo)
end
1 Like

Thanks for taking the time to patiently explain why my refactor was so unsuccessful. I’ve opted to go with cond, but would case be a faster and more efficient option?

1 Like

Optimise for readability until it’s a bottleneck IMO.

e: disregard, see benches below

2 Likes

Gotcha! Thanks so much for you insights. And thank you especially for referencing Keathley’s cheat sheet. Now, if you’ll excuse me, I’ve got a whole lotta refactoring to do, lol :smiley:

Use whatever suits your use case better.

1 Like

Actually thinking about it, the cond code isn’t very flexible, you’ll probably need to use match? in each clause.

I benched it as-is anyway:

code
x = {:ok, 1}

case_fn = fn ->
  case x do
    {:ok, _} -> :ok
    _ -> :error
  end
end

cond_fn = fn ->
  cond do
    {:ok, _} = x -> :ok
    true -> :error
  end
end

Benchee.run(
  %{
    "case" => case_fn,
    "cond" => cond_fn
  },
  time: 10,
  memory_time: 2
)
spoilers!
Operating System: Linux
CPU Information: Intel(R) Core(TM) i5-4670K CPU @ 3.40GHz
Number of Available Cores: 4
Available memory: 23.37 GB
Elixir 1.13.1
Erlang 24.2

Benchmark suite executing with the following configuration:
warmup: 2 s
time: 10 s
memory time: 2 s
parallel: 1
inputs: none specified
Estimated total run time: 28 s

Benchmarking case...
Benchmarking cond...

Name           ips        average  deviation         median         99th %
case        3.50 M        0.29 μs ±18914.94%       0.166 μs        0.58 μs
cond        0.76 M        1.32 μs  ±3154.19%        1.02 μs        1.90 μs

Comparison: 
case        3.50 M
cond        0.76 M - 4.61x slower +1.03 μs

Memory usage statistics:

Name    Memory usage
case         0.23 KB
cond         1.42 KB - 6.07x memory usage +1.19 KB

**All measurements for memory usage were the same**

cond performs “slightly” worse, at 4.6x slower and 6x more memory but that sounds like an Operations problem to me. Just buy a bigger instance :slight_smile:.

2 Likes