所以在another question的评论中，我刚看到这个例子来计算一个字符串中的L's数：
"hello".count('l'==)
足够疯狂..这很有效。
从完全展开的版本开始，我们有：
"hello".count(ch => ch == 'l')
然后可以将其缩减为：
"hello".count(_ == 'l')
但我们可以这样做：
"hello".count('l'==)
我想要... ??? ...
据推测，Scala推断我们必须在比较结束时添加_。 IMO，这是事情变得非常奇怪的地方;这对我来说似乎太过分了。任何人都可以解释允许这种语法背后的想法，或进一步阐明这一点吗？
如果您认为这很酷，那么我们如何证明不假设人们也可能想要==运算符，那么可以省略？然后我们可以：
"hello".count('l')
我认为我正在回忆到在perl中有10 ^ 99999种可能的做法的噩梦......
答案 0 :(得分：12)
您开始使用的“完全展开”版本实际上是向后的，它应该是：
"hello".count(ch => 'l' == ch)
但是，Scala语言并不认为==是特殊的，它只是Any的另一种方法。所以进一步扩展：
"hello".count(ch => 'l'.==(ch))
但请坚持......来自TraversableOnce的{{3}}方法期待一个带有签名(A) ⇒ Boolean的函数作为参数。 Any.==()的签名恰好是Any ⇒ Boolean，因此整齐地适合而无需包含在另一个匿名函数中。所以我们只能说：
"hello".count('l'.==)
或省略点：
"hello" count('l' ==)
为什么我们也不省略==运算符？好吧，我想你可以将countEqual定义为count(a => a ==)（或者，更简洁，count(_ ==)），如果你真的想......但你也可以定义countLowerCase管他呢。这里的要点是==并不特殊。
答案 1 :(得分：2)
首先，让我们考虑一下count的含义：
"hello".count('l'==)
count，这里是一个采用函数Char => Boolean的方法，因此它是'l'==所期望的。现在，让我们考虑一下：
'l' ==
这是==上的Char方法。该方法过载，但这个签名看起来很有趣：
def == (x: Char): Boolean
这意味着您有一个object.method，其类型为(x: Char): Boolean，在预期(x: Char) => Boolean的位置传递。还有什么要说的吗？