About ambiguity introduced in function default arguments

The difference is that in Supervisor example you have provided there is guard, which limits about of cases it will match.

So the expanded code will look like

def a(x) when is_list(x), do: …

def a(x), do: a(x, :default)

def a(x, y), do: …

So as you can see, there is a situation when 1st clause match.

If you swap order of these functions, then it will mean that there would be no option to call first clause.

I still don’t understand why switching the order would switch between warning and error.

Sidenote: Please upgrade the toolchain to Elixir1.20.1 / OTP29.

The compiler explicitly handles \\ operator because Erlang does not have default argument values. It does not allow any redeclaration after \\ has been expanded. Look-behind, though, would have a ton of redundant tracking involved, decreasing performance, that’s why it does not blow up immediately.

The error you observe is raised by first-pass compiler, meeting the \\ default parameters within the function redeclaration.

The warning you observe if you swap clauses is the second-pass compiler, simply warning you about unreachable clause, it has nothing to do with \\ because there is no look-behind.

You need to do it like this:

defmodule A do
  def f(a, b \\ [])

  def f(a, []), do: "f(#{inspect(a)})"
  def f(a, b) when is_list(b), do: "f(#{inspect(a)}, #{inspect(b)})"
end

IO.puts A.f(5)
# Output --> f(5)

IO.puts A.f(5, [:one, :two])
# Output --> f(5, [:one, :two])

yes, I know about this but this does not answer my question. thank you anyway!

It does not allow any redeclaration after \\ has been expanded. Look-behind, though, would have a ton of redundant tracking involved, decreasing performance, that’s why it does not blow up immediately.

this does make more sense to me, I guess there are no public documentation about this behavior.

Here is the documentation:

If a function with default values has multiple clauses, it is required to create a function head (a function definition without a body) for declaring defaults — Modules and functions — Elixir v1.20.2

Just don’t try to hack the proposed syntax. Supervisor also ditched this cludge, that’s why I suggested to use the latest versions of the toolchain.

It’s because of the declarative f/1 order.
When we write:

def f(a, b \\ [])

I fact the compiler will expand it in two functions:

def f(a), do: f(a, [])  # <-- This is not a declarative f/1 it's the default-argument of f/2
def f(a, b) do: ...

So in the first case

defmodule A do
  def f(a), do: "f(#{inspect(a)})"     # <--- declarative f/1

  def f(a, b \\ []) when is_list(b), do: ...   # <--- will be expanded by the compiler
end

You will have two f/1 but with the declarative f/1 in first position (top-bottom) will match all clauses. So the compiler emit a warning for the unreachable expanded f/1 that handle the default-argument case of f/2.

In the second case:

defmodule A do
  def f(a, b \\ []) when is_list(b), do ...   # <--- will be expanded by the compiler
  def f(a), do: "f(#{inspect(a)})"     # <--- declarative f/1
end

The declarative f/1 is after the expanded f/1 but from the compiler’s perspective, the expanded f/1 is not a declarative f/1 function it’s the mechanism that handle the default-argument of the f/2 function. So when later the compiler encounter the declarative f/1 which is in conflict with the auto-generated f/1 it emit a compilation error.

What’s “declarative function” and what does mean “in conflict” in regard to function clauses?

A declarative function is a function written by the coder in contrast with the auto-generated (or meta-programming) function written by the compiler.

In the first case, there isn’t any conflict with the declarative f/1 (meaning the coder want this function), so when calling f/1 the declarative f/1 will be called. The compiler emit a warning saying “hey I’m doing a trick to handle the default-argument case of f/2 but it will not work” because of the declarative f/1 that will match all clauses about f/1).

In the second case, the compiler is doing his trick to handle the default-argument of f/2, so it add a f/1 but this auto-generated f/1 break the intent of the coder who declared his own f/1. This f/1 will never be called because of the auto-generated f/1, so in this case there is a conflict (breaking coder intent). This is why the compiler emit an error (“I’m doing something that break your intent”):

error: def f/1 conflicts with defaults from f/2

PS:

def f([]), do: ...   # <-- not matching all possible clauses of f/1 (only matching [] clause)
def f(5), do: ...

def f(a), do: ...    # <--- matching all possibles clauses