What about this?

case {f.(), g.()} do
  {x, y} -> #whatever
end

a = fast_op()
b = long_running_thing()

case c do
  ^a -> 1
  ^b -> 2
end

Is very explicit that no matching would happen before both calls have returned, whereas the “sugared” version you suggest might hide this fact and a naive reader would assume that long_running_thing() never gets called when cmatches the result of fast_op().

Matches are run in linear time, they can’t allow for arbitrary function calling or anything of the sort as they get compiled to a fairly efficient jumplist (sometimes).

Doesn’t this crash as soon as fast_op/0s return value isn’t matching cs value?

I think its this you mean:

cond do
  c === fast_op() -> 1
  c === long_running_thing() -> 2
end

Given that you can just assign the result of a function call to a variable and match on that it’s always seemed surprising to me that the compiler doesn’t do this for you. Is there a technical reason for this not being supported or is it something that might happen at some point?