# Multiple clauses, defaults and conflicts

Hi,

When writing the following code, elixir correctly and thankfully warns that there is a conflict:

function/macro 1:

``````defmacro static_translate(key, opts \\ [humanize: :true, downcase: :true]) do
... do stuff here
end
``````

function/macro 2:

``````defmacro static_translate(module, key, opts \\ [humanize: :true, downcase: :true]) do
...do other stuff here
end
``````

error

``````web/views/views_translation_helpers.ex:59: defmacro static_translate/3 defaults conflicts with defmacro static_translate/2
``````

I’ve been dealing with these situations a few times and I’m never quite happy with my refactoring…

how would you rewrite this?

(please assume the function logic is sufficiently different to warrant a separate function completely)

The only possible way to refactor here is to rename one of the macros/functions.

``````def foo(bar, baz \\ []), do: ...

def foo(quux, bar, baz \\ %{}), do ...
``````

is getting expanded at compile time to the following:

``````def foo(bar), do: foo(bar, [])
def foo(bar, baz), do: ...

def foo(quux, bar), do: foo(quux, bar, %{})
def foo(quux, bar, baz), do: ...
``````

As you can see, there are now 2 `foo/2`, which is the mentioned conflict in the error you posted.

6 Likes

Thanks for the answer… This is what I did in the end.

My refactoring ended up like this…

``````defmacro static_translate(key, opts \\ [humanize: :true, downcase: :true]) do
end
``````
``````defmacro dynamic_translate(key, opts \\ [humanize: :true, downcase: :true]) do
module = MyApp.module
......
end
``````

I wasn’t sure if renaming was bad or not. In this case, it turned out better because the second one is a dynamic translation – but regardless of that if it wasn’t, I would not have wanted to rename… but if this is the only way, then so be it.

Cheers for your input.

This is why I link to call everything via Modules. I have `alias MyServer.Perms` for everything related to Perm is called like `Perms.Admin.blah` and so forth. If it is a long module name I `:as` it to something shorter, but I always like to have names being called. It prevents these issues and lets me know ‘where’ something is that I am calling.

EDIT: Or wait, I think your above functions are in the same module? Yeah that is a big conflict then.

Either make different names for them (as you did) or make a ‘header’ function that calls whichever specific it needs.

Looks to me like you’re saying `module` is optional… so maybe you could make `module` one of the `opts`?

1 Like

in this case module is not optional but fair suggestion…

Good explanation. I get similar error but in a case a bit different. For example:

``````iex(1)> defmodule Test do
...(1)> def same({a, b}, c), do: 1
...(1)> def same({a, b}), do: 2
...(1)> def same(a, b, c \\ 1), do: 3
...(1)> end
iex(2)> Test.same({:ok, :ok})
2
iex(3)> Test.same({:ok, :ok}, :ok)
1
iex(4)> Test.same(:ok, :ok, :ok)
3
iex(5)> Test.same(:ok, :ok)
3
``````

With that code everything well. But if I try to do that `c` to be optional for the case where I match with a tuple of 2 elements then I get the error about defaults conflicts.

``````iex(8)> defmodule TestAgain do
...(8)> def same({a, b}, c \\ 1), do: 1
...(8)> def same(a, b, c \\ 1), do: 3
...(8)> end

** (CompileError) iex:10: def same/3 defaults conflicts with same/2
iex:10: (module)
``````

But the code that, if I understood well, is equivalent to `same({a, b}, c \\ 1)` works well. Could this case be an error in compiler that check the number of arguments but does not check the pattern matching in arguments?

(I replied in this thread as it’s about same topic, I’m not sure if it’s better open new thread or to reply here).

Welcome to the forum!

``````same({1,2},3)
``````

could be interpreted verbatim as calling `same/2` or as

``````same({1,2}, 3, 1)
``````

due to the optional parameter on `same/3`.

How is the compiler supposed to know which one you mean?

Don’t mistake pattern matching for static typing.

Note:

``````iex(1)> defmodule Test do
...(1)>   # same/3
...(1)>   def same(_a, _b, _c \\ 1), do: 3
...(1)>   # same/2
...(1)>   def same({_a, _b}, _c), do: 2
...(1)>   # same/1
...(1)>   def same({_a, _b}), do: 1
...(1)> end
** (CompileError) iex:5: def same/2 conflicts with defaults from same/3
iex:5: (module)
iex(1)>
``````

i.e. you should have gotten an error on your first example.

Your ordering happened to create this:

``````iex(1)> defmodule Test do
...(1)>   # same/1
...(1)>   def same({_a, _b}), do: 1
...(1)>   # same/2
...(1)>   def same({_a, _b}, _c), do: 2
...(1)>   def same(a, b), do: same(a, b, 1)
...(1)>   # same/3
...(1)>   def same(_a, _b, _c), do: 3
...(1)> end
{:module, Test,
<<70, 79, 82, 49, 0, 0, 4, 240, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 0, 123,
0, 0, 0, 13, 11, 69, 108, 105, 120, 105, 114, 46, 84, 101, 115, 116, 8, 95,
95, 105, 110, 102, 111, 95, 95, 7, 99, ...>>, {:same, 3}}
iex(2)> Test.same({:ok, :ok})
1
iex(3)> Test.same({:ok, :ok}, :ok)
2
iex(4)> Test.same(:ok, :ok, :ok)
3
iex(5)> Test.same(:ok, :ok)
3
iex(6)>
``````

The behaviour you are looking for seems to be this:

``````iex(1)> defmodule Test do
...(1)>   # same/1
...(1)>   def same({_,_} = arg), do: same(arg, 1)
...(1)>   # same/2
...(1)>   def same({_a,_b}, _c), do: 2
...(1)>   def same(a,b), do: same(a,b, 1)
...(1)>   # same/3
...(1)>   def same(_a, _b, _c), do: 3
...(1)> end
{:module, Test,
<<70, 79, 82, 49, 0, 0, 5, 8, 66, 69, 65, 77, 65, 116, 85, 56, 0, 0, 0, 123, 0,
0, 0, 13, 11, 69, 108, 105, 120, 105, 114, 46, 84, 101, 115, 116, 8, 95, 95,
105, 110, 102, 111, 95, 95, 7, 99, ...>>, {:same, 3}}
iex(2)>
nil
iex(3)> Test.same({:ok,:ok})
2
iex(4)> Test.same({:ok,:ok}, :ok)
2
iex(5)> Test.same(:ok, :ok)
3
iex(6)> Test.same(:ok, :ok, :ok)
3
iex(7)>
``````
2 Likes

Thanks!

``````same({1,2},3)
``````

could be interpreted verbatim as calling `same/2` or as

``````same({1,2}, 3, 1)
``````

due to the optional parameter on `same/3` .

How is the compiler supposed to know which one you mean?

Then I din’t understand the explanaiton of @NobbZ because what I understood is not that `same({a, b}, c)` could be interpreted as a call to `same/2` or `same/3` and then it check what call to do. I though what it is expanded to 2 definitions, then the previous call always will be `same/2` and then as the pattern matching in the argument is before of same arity without that it’ll match with the first (as it’s expected).

@NobbZ said:

``````def foo(bar, baz \\ []), do: ...

def foo(quux, bar, baz \\ %{}), do ...
``````

is getting expanded at compile time to the following:

``````def foo(bar), do: foo(bar, [])
def foo(bar, baz), do: ...

def foo(quux, bar), do: foo(quux, bar, %{})
def foo(quux, bar, baz), do: ...
``````

Then, in that example 2 functions have same arity and don’t do pattern matching in one, then I won’t can call to both; but with the pattern matching in one argument, if this is before of argument without it, I’ll can call to both. Of course, there is not so much sense to order with same arity without the tuple matching in one argument first because then nothing will match because it’s checked in order. But, if:

``````def foo({bar, bax}, baz \\ []), do: ...

def foo(quux, bar, baz \\ %{}), do ...
``````

is getting expanded at compile time to the following:

``````def foo({bar, bax}), do: foo({bar, bax}, [])
def foo({bar, bax}, baz), do: ...

def foo(quux, bar), do: foo(quux, bar, %{})
def foo(quux, bar, baz), do: ...
``````

As, if it’s correct, the expansion is in the function code, not in the call, a call as `foo({1, 2}, 3)` is always `foo/2` then it must match with:

``````def foo({bar, bax}, baz), do: ...
def foo(quux, bar), do: foo(quux, bar, %{})
``````

And because the order is correct, with the argument that match the tuple before, then it’ll match with first of `foo/2`. Then my second example in first post:

``````...(8)> def same({a, b}, c \\ 1), do: 1
...(8)> def same(a, b, c \\ 1), do: 3
``````

if expands to:

``````def same({a, b}), do: foo({a, b}, 1)
def same({a, b}, c), do: ...

def same(a, b), do: foo(a, b, 1)
def same(a, b, c), do: ...
``````

Must works (and it works if I write as it’s expanded), then if compiler can’t expand a code that’s correct when it’s write as expanded, isn’t it an error? I understand that if it only check arity then try to avoid error, but when it as matchings in arguments it could be correct and works. Only problem could be if it doesn’t expand the function definition and it expand functions calls, that I didn’t understood that way.

The behaviour you are looking for seems to be this:

``````iex(1)> defmodule Test do
...(1)>   # same/1
...(1)>   def same({_,_} = arg), do: same(arg, 1)
...(1)>   # same/2
...(1)>   def same({_a,_b}, _c), do: 2
...(1)>   def same(a,b), do: same(a,b, 1)
...(1)>   # same/3
...(1)>   def same(_a, _b, _c), do: 3
...(1)> end
``````

Yes, I used 1, 2 &3 only to show in console where it did the call, but that’s the correct behaviour. What I tried to tell is what that could be written as:

``````iex(1)> defmodule Test do
...(1)>   def same({_a,_b}, _c \\ 1), do: 2
...(1)>   def same(_a, _b, _c \\ 1), do: 3
...(1)> end
``````

And expanded to:

``````iex(1)> defmodule Test do
...(1)>   # same/1
...(1)>   def same({_,_} = arg), do: same(arg, 1)
...(1)>   # same/2
...(1)>   def same({_a,_b}, _c), do: 2
...(1)>   def same(a,b), do: same(a,b, 1)
...(1)>   # same/3
...(1)>   def same(_a, _b, _c), do: 3
...(1)> end
``````

But:

``````iex(22)> defmodule Test do
...(22)> def same({_a,_b}, _c \\ 1), do: 2
...(22)> def same(_a, _b, _c \\ 1), do: 3
...(22)> end
** (CompileError) iex:24: def same/3 defaults conflicts with same/2
iex:24: (module)
``````

When the expected expand will work well and won’t raise errors compiling the expanded version.

Then, maybe compiler could not to raise the error when even arity is same the arguments have something that can match, specially when the order is correct (if order is not good compiler show a warning), not to force to write the expanded version when the idea of `\\`, I think, is not to write the expanded version, to do same with less, compiler is not avoiding error, is raising an error in a code that expanded will work well.

EDIT: Or I’m ignoring something I don’t know/understood about expansion and the compiler and it makes sense not to do that expansion and avoid it to avoid errors.

1 Like

That is actually

``````# same/1
def same({a, b}), do: same({a, b}, 1)

# same/2
def same({a, b}, c), do: ...
def same(a, b), do: same(a, b, 1)

# same/3
def same(a, b, c), do: ...
``````

which is equivalent to

``````# same/1
def same({a, b}), do: same({a, b}, 1)

# same/2
def same(arg, c) do
case arg do
{a,b} -> ...
_ -> same(arg, c, 1)
end
end

# same/3
def same(a, b, c), do: ...
``````

Optional parameters are not a feature of the underlying language - Erlang. It’s something that Elixir layers on top in a way that “works most of the time as expected”. But there can be surprising edge cases.

This creates ONE function (`same/2`):

``````def same({a, b}, c), do: ...
def same(a, b), do: ...
``````

This creates TWO functions (`same/2` and `same/3`):

``````def same(a, b, c \\ 1), do: ...
``````

Taking that into account

``````# this emits code for same/1 and same/2
def same({a, b}, c \\ 1), do: 2

# this emits code for same/2 and same/3
def same(a, b, c \\ 1), do: 3
``````

The error probably relates to the fact that two separate clauses with optional function parameters emit code for the same function: `same/2`.

The intent that is behind

``````def same({_a,_b}, _c \\ 1), do: 2
def same(_a, _b, _c \\ 1), do: 3
``````

cannot be implemented with optional parameters but can be implemented long-hand

``````def same({_,_} = arg), do: same(arg, 1)

def same({_a,_b}, _c), do: 2
def same(a,b), do: same(a,b, 1)

def same(_a, _b, _c), do: 3
``````
2 Likes

Thanks @peerreynders I think I get it now with:

Optional parameters are not a feature of the underlying language - Erlang. It’s something that Elixir layers on top in a way that “works most of the time as expected”. But there can be surprising edge cases.

This creates ONE function ( `same/2` ):

``````def same({a, b}, c), do: ...
def same(a, b), do: ...
``````

I expected Elixir could handle it. I guess I found one of that surprising edge cases.

I don’t know if to enhance optional parameters is in the roadmap (in the end, it’s not important as it can be handle long-hand) but it’s nice, hopeful it’ll have less edge cases over time.

Thank you so much for the explanation!