Yeah, I did state certain patterns.
Schultzer
jhogberg
Erlang Core Team
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.
6
