Is "Pimp my Library", as used to be recommended by Odersky, also an anti-pattern now? It uses implicit conversions, if I'm not mistaken.

No, Pimp my Library is not an anti-pattern. It even received dedicated syntax with `implicit class`es. Contrary to general implicit conversions, implicit classes are not dangerous because things are not actually converted as far as the developer can see (yes, under the hood, it's an implicit conversion, but it doesn't bite you). You're simply adding methods on existing classes, which is similar to extension methods in several other languages.

And in fact, if you combine implicit classes with values classes (e.g. implicit class RichFoo(val value: Foo) extends AnyVal { ... }) then you're effectively just adding extension methods, and there's not even an allocation involved.

I didn't even know implicit classes existed. Thanks!

It does, and yes I think it is now considered an anti-pattern. The proper way (IMO) to extend libraries is to use type-classes.

It would be more accurate to say that abuse of implicit conversions are now considered an anti-pattern. They are a core part of the language e.g. many of the extra functions Scala adds to java's String class.

> implicit def intToFloat(x: Int) = x.toFloat

I've seen code like this pop up way more than I'm comfortable admitting.

This is such an interesting choice of example because this particular implicit is baked into the language, and the discomfort you feel is a fine measure of how good an idea this is. Last I checked there was no way to turn it off.

  scala> def f(x: Float) = x.round
  f: (x: Float)Int

  scala> f(123456789)
  res0: Int = 123456792

But of course it doesn't stop at converting Ints into Floats.

  scala> f(Long.MaxValue)
  res1: Int = 2147483647

So it seems 9223372036854775807 rounds to 2147483647. This can be a real simplifier if your "big data" is getting too big.

This is an anti-pattern IMO and requires an import to opt-in (by the author, not the caller IIRC). Instead you'd use an implicit value class which should be zero overhead.

But that's just about the definition, not what it's doing which is no good. Anyone can abuse a lot of these features, which depending upon who you'd ask, is better flexibility than not having them at all.

You can write bad code in any language.

This is true, and in some ways I get annoyed by this saying, because it doesn't add much value.

I think there are two better ways of evaluating a language in terms of good code/bad code:

1. Does the language (and its idioms) encourage good or bad code?

2. Does the language support strong enough abstraction facilities to allow good code to be written?

Now, of course, the problem is that people will disagree about what counts as good code, but these at least make you think about what's important in a language.

Edit: Formatting

Really? Nice to know.

I had the feeling that "Programming in Scala" prized them as the killer feature, back in 2009 :)

Yes, you have to explicitly enable it otherwise it triggers a compiler error.

Explicitly enable implicit conversions? ´ Nice play, Mr. Odersky...

You have to explicitly enable the definition of new implicit conversions. Usage of implicit conversions is automatic.

However, they are heavily used in standard library, e.g. the dreadful CanBuildFrom

That's an implicit parameter, something entirely different. It is unfortunate that so many critics conflate the two.

Implicit parameters are not the same as implicit conversions.

Implicit parameters are no prize either, though. They seem to lead to massive, massive snarls in the codebases I end up exposed to regularly.