匹配表达式的语法非常好：
expr match {
case Test(l1) => ...
...
}
但这让我发疯，我不明白为什么使用这种语法而不是 的动机match (expr) ...，就像在一个体面的 C 后代中的分支语句一样！
我认为对此没有合理的解释。而且我在 Programming in Scala、Scala 网站、in this paper、this thesis、here on SO 和其他网络上都找不到答案。
并不是它有什么问题，只是它完全是个谜。当以这种方式工作时，match为什么不呢？iffor
有人知道吗？我认为我不能再忍受使用这种语言而不发现这一点。我一直在想。我晚上几乎睡不着。
为了采用类似的 Scala 语法，模式匹配案例中的守卫不需要在其条件表达式周围加上括号——例如，以下内容：
case i if i % 2 == 0 => i / 2
和这个一样有效：
case i if (i % 2 == 0) => i / 2
坚持 C 系列风格意味着需要后一种形式，即使括号对于消除歧义不是必需的。Scala 语言设计者决定在这种情况下减少线路噪声胜过保持家族相似性。
我猜想类似的动机也在match语法中起作用，在我看来match (expr) { ... }，与expr match { ... }.
另外，就在今天下午，我重构了其他人的x match { ... }toOption代替x map { ... }。match作为中缀运算符使这两个表达式之间的相似性变得清晰。
关于为什么match不只是一种方法的问题，这里是大卫波拉克在邮件列表中提出的一个五年前的scala-debate问题：
为什么“匹配”是语言级别的构造而不是 Any 上的方法？
马丁·奥德斯基的回答：
在 Scala 1 中曾经是这样的。我不再确定我们为什么要改变。语法高亮？错误报告？没有把握。不过，我认为这两种方式都不重要。
我和马丁在这件事上。
请注意，存在一些实际差异（除了简单的“点与否”问题）。例如，这不会编译：
def foo[A, B](f: PartialFunction[A, B])(a: A) = a match f
如果match仍然是 on 的一个方法Any，那么需要一堆字面上的案例将是一个相当奇怪的要求。