Yep! Which is why I would really love a new unary operator for it, could just do something like filter x<y (which could work for matchers too like filter {:ok, blah} = something(x)) but the word is easy to ignore as ‘just another command’ where an operator would be explicit, could usurp @ perhaps but that already has a meaning so could get confused, etc…
Exactly, hence some new distinguishing operator or syntax. A binary operator could work as a filtering match expression but then a binary op could get ignored accidentally when reading the code unless it was sufficiently different from <-, but that is a possibility too. I rather like the idea of a prefix unary operator as then it could do simple not in [false, nil] test if a matcher via a noon-simple-binder = is not otherwise supplied.
Entirely agree! I couldn’t figure out something that I really liked in elixir’s current parser to use so that’s why my comp went with the explicit x <- match y style.
