Composition of pattern questions

[Brian Goetz]

>> _two_ features (& composition and true/false patterns) to get to a guard
>> in a switch seems too roundabout, and you want something more direct?
> The JEP is already telling you that guards are not the same as other
> patterns - that they are pattern modifiers, not patterns.

That's an interesting interpretation -- where do you get that from? The 
intent is that they are true (heh) patterns (they have all the things 
pattern have), but, just as with some other types of patterns, there are 
limits to which pattern contexts they can appear in (here, only on the 
RHS of an &).

The limitation to the RHS is not even fundamental, as much as attempting 
to avoid confusion, and we might someday relax that.  For example, 
here's a weird off-label use of true/false patterns that would be 
useful, if weird, if we were to allow this:

     switch (ignored) {
         case true(x > 3): A
         case true(x < 3 && y > 0): B
         default: C
     }

This is morally an if-then-else chain, but the "pick exactly one" is 
more explicit, and the conditions are brought a little closer to the 
user's view.  OTOH, it's grotty to have a switch ignore its target. 
(OTOOH, maybe someday switches will be more flexible about their target 
arity, and zero will be a valid choice.)

> I don't
> think guard patterns work out that well, especially in syntax. The
> extra & is jarring particularly as it is not adding anything
> meaningful.

Again, I think your real objection is: "I have to use two language 
features -- a pattern and a combinator -- to express a simple boolean 
filtering."  Yes?

> Having just done a presentation on patterns, I think it is simpler to
> explain that a guard can be added to any pattern:
> "
> There are various types of pattern, eg. type, array and record
> Patterns can be nested
> Patterns can be composed
> Any pattern can have a guard, to modify its behaviour (including
> nested and composed ones)

This turns guard into its own concept, rather than being just another 
kind of pattern.  I think your argument is that users will be more 
receptive to the multiplicity of concepts, in preference to one richer 
but more complex concept?