Jon Pretty

Implicits are widely accepted because of typeclasses. Using them simply as a way of avoiding passing arguments (non-typeclass) is their most common abuse.

Typesclasses are implicit passing of dictionaries, which could, and some argue should, be passed explicitly. I like typeclasses, but ridiculing entire communities for doing something that we do *all the time* seems a little bit unfair.

“No but the way *I* do it is morally acceptable” is, on average, not an argument that starts well for the person making it.

For me, "argument autowiring" is acceptable when: - it happens in compile time - parameter type is specifically designed for that - there is (by desing) at most one candidate in scope which is generally true for typeclasses and may be true for plain DI

In other words: if it's obvious what would you pass then you can let the compiler do it for you.

I disagree that this argument applies to type classes though. I've had quite a few subtle bugs because the wrong instance was being picked up (at least in Scala, where orphan instances are not considered an antipattern).

But the argument wasn't specific to type classes - implicits *are* a convoluted way to avoid passing arguments to function. Scala does plenty of it without even talking about type classes: ExecutionContext comes to mind, for example.

I don't disagree with you. When a typeclass has more than one instance then things can go awry. And I'm totally not a fan of ExecutionContext. All these things are still far better than what we see in Java style DI frameworks.