For anything cited as a shortcoming of the language or dev environment, there's going to be some tooling. There's a search engine for those symbolic "operators"

For anything cited as a shortcoming of the language or dev environment, there's going to be some tooling. There's a search engine for those symbolic "operators" (they're methods, not operators, but that's how most devs think about them - (Scalex)[http://scalex.org/ http://scalex.org/] search engine should cover most of them. Generally, you know if that "operator" comes from the collections API, scalaz, sbt, akka, or wherever, so it's not that hard to locate the scaladoc and the source. - (Staircase book, first edition)[http://www.artima.com/pins1ed/book-index.html#indexanchor http://www.artima.com/pins1ed/book-index.html#indexanchor] covers most the built in and standard lib symbolic operators - aliases like foldLeft and foldRight are built into List class, for example, for /: and \: Implicits: - you can look at them using ":implicits" in the 2.9 REPL and the IDEA plugin and (I think) new eclipse plugins popup bubbles when you cursor over an object or class that has implicits, and shows you the implicit's source - implicit conversions of method receivers (as opposed to implicit parameters) are useful as typeclasses are used in haskell, or structural typing in other languages. A best practice is to have all implicits declare a return type, and there was a discussion of having the compiler enforce this, or at least issue warnings. [http://scalatips.tumblr.com/post/101578787/add-explicit-return-types-to-all-implicits http://scalatips.tumblr.com/post/101578787/add-explicit-retu...]