It makes no difference at all with regards to efficiency. Literally the complier translates it into almost the same code with the main difference being what error you will get.

Yes, precisely, and I think a good example that may illustrate what I’m trying to say a little better may be –

Let’s consider for a moment that my app is capable of communicating with Google Bard as well as OpenAI,

My LiveView may make a function call like this:

MyContext.complete_chat%{messages: messages, ai_service: :open_ai})

In my context, I unwrap only what’s necessary to determine which function head to take:

def complete_chat(%{ai_service: :open_ai} = attrs) do
  %{messages: messages} = attrs
  # call openai api here
end

def complete_chat(%{ai_service: :google_bard} = attrs) do
  %{messages: messages} = attrs
  # call google bard here
end

MatchErrors now point me directly to the specific function head where the error occurred

Pattern matching in the function head should be used for flow control.

Pattern matching in the body of the function should be “this function requires this data”

It’s a subtle but important distinction.

Yes MatchError is better than FunctionClauseError, especially in the case where you have multiple function heads. It is much easier to jump to the line number of the MatchError than it is to figure out which function head is missing an assign in a large assigns crash dump.

Elixir will only show the line number of the first defined function head (on a FunctionClauseError). It will also log each function head it attempted to take - if each function head is unwrapping several values that are orthogonal to the flow control, it becomes difficult to tell which one should have been taken.

That leaves the developer in the unfortunate position of figuring out

1. Which function head should have been taken with this call?
2. Which missing value caused this function invocation to fail?

I understand and I do empathize. I often find myself wanting to unwrap everything in the function head. I’ve found, however, after over 4 years of production elixir, that it causes more problems than it solves

in particular, how do you square:

function head pattern matching is an all-or-nothing

with:

When the sizes are manageable it’s very easy to tell which function head was attempted

At a certain point, especially on a team, the sizes of parameters are going to get large. It’s inevitable. is it all-or-nothing, or is it a manageable size?

And, to be honest I’m not sure I totally understand this question:

Why do we get FunctionClauseError at this non-early stage of the project still

If you are suggesting we all write error-free code, I agree, but I don’t know how practical that is. FunctionClauseErrors aren’t exclusive to third-party apis, and, like everything in software – things change. To suggest “just don’t write code that throws a FunctionClauseError” seems misled

In any case – I have genuinely enjoyed this discussion with you as I love discussing the ins-and-outs of Elixir with whoever is unfortunate enough to be within earshot , especially so with those whom which I disagree. There is no growth without disagreement. All that to say that I hope my tone has not come off as disrespectful which I know it has the possibility to do over text, especially over the wider internet