Pattern matching with conjunctions (PatternA AND PatternB)

Scala has a language feature to support disjunctions in pattern matching ('Pattern Alternatives'):

x match {
    case _: String | _: Int => 
    case _ =>
}

However, I often need to trigger an action if the scrutiny satisfies PatternA and PatternB (conjunction.)

I created a pattern combinator '&&' that adds this capability. Three little lines that remind me why I love Scala!

// Splitter to apply two pattern matches on the same scrutiny.
object && {
  def unapply[A](a: A) = Some((a, a))
}

// Extractor object matching first character.
object StartsWith {
  def unapply(s: String) = s.headOption
}

// Extractor object matching last character.
object EndsWith {
  def unapply(s: String) = s.reverse.headOption
}

// Extractor object matching length.
object Length {
  def unapply(s: String) = Some(s.length)
}

"foo" match {
  case StartsWith('f') && EndsWith('f') => "f.*f"
  case StartsWith('f') && EndsWith(e) && Length(3) if "aeiou".contains(e) => "f..[aeiou]"
  case _ => "_"
}

Points for discussion

1. Is there an existing way to do this?
2. Are there problems with this approach?
3. Can this approach create any other useful combinators? (for example, Not)
4. Should such a combinator be added to the standard library?

UPDATE I've just been asked how the compiler interprets case A && B && C. These are infix operator patterns (Section 8.1.9 of the Scala Reference). You could also express this with standard extract patterns (8.1.7) as &&(&&(A, B), C).' No开发者_Go百科tice how the expressions are associated left to right, as per normal infix operator method calls likeBoolean#&&inval b = true && false && true`.

I really like this trick. I do not know of any existing way to do this, and I don't foresee any problem with it -- which doesn't mean much, though. I can't think of any way to create a Not.

As for adding it to the standard library... perhaps. But I think it's a bit hard. On the other hand, how about talking Scalaz people into including it? It looks much more like their own bailiwick.

A possible problem with this is the bloated translation that the pattern matcher generates. Here is the translation of the sample program, generated with scalac -print. Even -optimise fails to simplify the if (true) "_" else throw new MatchError() expressions.

Large pattern matches already generate more bytecode than is legal for a single method, and use of this combinator may amplify that problem.

If && was built into the language, perhaps the translation could be smarter. Alternatively, small improvements to -optimise could help.