Are you really OK with runtime "expression patterns"? match (0, 1, 2) { case (F(), 0, G()) => ... } > Here (F(), 0, G()) is not an expression, b

Are you really OK with runtime "expression patterns"? match (0, 1, 2) { case (F(), 0, G()) => ... } > Here (F(), 0, G()) is not an expression, but three separate expressions in a tuple pattern. As a result, this code will call F() but not G(), because the mismatch between the middle tuple elements will cause pattern matching to fail before reaching G(). Other than this short-circuiting behavior, a tuple pattern of expression patterns behaves the same as if it were a single expression pattern. How would that work with exhaustiveness checking? As far as I can tell, they themselves believe that Carbon's exhaustiveness checking will be very poor. And OK with implicit conversions? Especially when combined with their way of handling templates for pattern matching?