Variable cycle detection in patterns rejects valid patterns since 1.18

[lukaszsamson]

Existing issue

• I have searched existing issues and could not find a duplicate.

Elixir and Erlang/OTP versions

Erlang/OTP 28 [erts-16.4.0.1] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [jit]

Elixir 1.20.1 (compiled with Erlang/OTP 28)
Affected versions: all since 1.18.0

Operating system

any

Current behavior

Pattern variable cycle validation introduced in commit 860f485 rejects valid code when the same variable appears on the left and right

The following code reproduces the issue on 1.18+

fn %{a: v} = %{b: v} -> v end
error: recursive variable definition in patterns:

[%{a: v} = %{b: v}]

the variable "v" is defined in function of itself
└─ iex:1

** (CompileError) cannot compile code (errors have been logged)

Whereas on 1.17.3:

f = fn %{a: v} = %{b: v} -> v end
#Function<42.105768164/1 in :erl_eval.expr/6>
f.(%{a: 1, b: 1})
1

Similar behaviour

fn {v, _} = {_, v} -> v end

Expected behavior

patterns-and-guards.md does not document this as not supported so I expect it to compile fine. Equivalent code works and unifies in erlang (tested on OTP 28)

F = fun(#{a := V} = #{b := V}) -> V end.
#Fun<erl_eval.42.113135111>
F(#{a => 1, b => 1}).
1

[josevalim]

That is intentional and covered in the later part of the commit, although we could have given more examples.

We also no longer accept {:ok, x} = {x, :ok} even though it can work. Maps do give a bit more range as you can use separate keys but it still overly complicates any sort of later analysis. Erlang is deprecating similar constructs too!

[lukaszsamson]

Interesting , I haven't noticed erlang/otp#10433.

That is intentional

OK, then let's improve the documentation and maybe error message because right now it's misleading