But in only works that way in guards for fixed compile time lists. It doesn’t work with runtime lists.

EDIT: Elaborating a bit now that I’m not on mobile.

You can do:

def foo(x) when x in [1,2,3] do

which will turn into

def foo(x) when x == 1 or x == 2 or x ==3 do

but what you can’t do is:

def foo(x, list) when x in list do

No, the restriction is artificial. User-defined guards running arbitrary code would not be difficult to support from a technical point of view (we already do it, see prim_eval.S and its interaction with :erl_eval), it’s just very annoying to define what’s supposed to happen in corner cases like such a guard running a receive while in a receive, how exception tracing is supposed to work, and the likes.

So why don’t we support it?

Partially because it’s a bit of a footgun. If you end up throwing a user-defined guard into an infinite loop, which specific clause was it “called from?” If you accidentally make it side-effecting, which combination of the (say) three hidden invocations derailed things?

The main reason however is historical and there’s been no pressing need to change it. You can case over the result in the function body, and that’s been enough so far.

This is a non-starter (there is a reason the language doesn’t come with one).

TL;DR:
You cannot reliably fully traverse a list fast enough to be viable in guards.
As such, you cannot exhaustively ensure every item of a list is a Keyword pair in a guard.

Keyword lists are just lists (of atom/any two-tuples {atom, term}), which are singly-linked car/cons cells that require O(n) time to traverse.

Matches and guards are required to have near-constant-time access to data structures, since they are used in places in the VM with tight performance requirements (like selecting a function head to invoke from many given certain arguments).

This is why tuple and map indexing are allowed in guards (with integer-based elem(tuple, n) and key-based is_map_key(map, key) or :erlang.map_get(map, key)), their structures offer constant-time access to the data they compose. (Also why you can destructure on them in matches.)

I say “near” constant-time because you are also allowed to “peek” into the heads of O(n)-traversable data structures when such an operation is known to be fast and bounded (with hd in guards for lists, binary_part in guards for binaries, and destructuring in match patterns: [first | rest] for lists, "start" <> rest for strings, <<leading, rest::binary>> for binaries).

In practice this peeking is just enough to enable function clauses to recursively consume these O(n) datastructures piece-by-piece, using matching and guards to decide how to handle each chunk. Useful enough, we make concessions on the constant-time constraint.

However, fully accessing every item in a list is an unbounded operation, so, not allowed—even a theoretical “recursive” implementation (that guards are, by design, not expressive enough to support).

What your original macro (and what @Schultzer’s guard) attempts to do is just evaluate the first “peeked” term of a list for Keyword-iness, which could be useful in some contexts, but is generally insufficient to ensure that every item in a list is a keyword pair. And you can’t traverse every item in a list in guards, for reasons explained above.

To follow up on @jhogberg answer of this not being true: length/1 is a guard and completes in linear time by my understanding.

I would say it is doable. You can mimic what the Kernel.in/2 operator does. Instead of checking for values you check for every element in the list being 2-element tuple and the first element being an atom (all operations allowed in guards). If the context of the call is not a match or a guard, you delegate to Keyword.keyword?/1.

Here’s the in/2 implementation: elixir/lib/elixir/lib/kernel.ex at v1.18.4 · elixir-lang/elixir · GitHub

What you end up doing is building are nested conditions similar to this

but with :erlang.andalso/2.