You nail the guard to a pattern, which is equivalent until we have
nested patterns (and "or"/"and" patterns).
We have nested patterns already in the JEPs on the table. Where's the
problem?
I see a lot of advantages of using && to link a guard to a pattern,
- the symbol is heavy so there is a clear visual separation
- without any supplementary parenthesis, && after the type pattern in
an instanceofis the && between expression, it's almost like you can
not have a guard with an instanceof, in practice, few instanceof will
have a guard.
I agree few instanceof will have a guard, but users are still free to
express it that way if they like, and there's nothing wrong with that.
I still think that using a guard inside a nested pattern is ugly but
it can be just that, ugly. Someone may want a short-circuit in a
deeply nested patterns .
Yes. This is not unlike other compositions; for any compositional tool,
you can overuse it. (You can arbitrarily compose boolean expressions
(or arbitrarily chain method invocations), but sometimes this is taking
it too far.)
As i said to Gavin, i'm not at ease with using the symbol '&' in
between patterns.
I think that this is mostly a "who moved my cheese" reaction; you're
used to thinking that & is just for bitwise operations. But, that's not
actually true; we already use & and | on types -- intersection type
casts, additional generic type bounds, multi-catch. This appeals to a
notion that & and | are boolean-like combinators on types (even if not
exposed in all places they might make sense), but this is a different
kind of combination than on integers. And yet a different kind of
combination on patterns. (In an alternate universe, we might have
different symbols for adding ints vs floats vs string concatenation, but
+ works well enough that overloading the symbols is OK -- because using
+ in this way appeals to the underlying algebraic monoid structure these
types share.)
The reason that & and | make sense on patterns, and on types, is that,
like the more familiar versions on bits, they describe a _boolean
algebra_. Boolean algebras have familiar properties such as De Morgan's
Laws. These work for types (when interpreted as value sets) as well as
bits, and they work for patterns too.
I think where you're getting hung up is that when patterns produce
bindings, and other patterns consume those bindings, we have a dataflow
dependence which would appear to undermine certain other expected
properties of a boolean algebra, such as commutativity. But, if we view
those dataflow dependencies as a separate constraint -- as we *already
do* for ints (e.g., `(x=3)&(x|4)`, is invalid when `x` is an DU int, but
valid when `x` is DA), this seeming contradiction vanishes, and is seen
to be merely a post-hoc well-formedness constraint. If the WF
constraint is satisfied, the expected properties of boolean algebras
(associativity, commutativity, absorption, etc) are satisfied too.
