Allow implicit conversions to have a parameter of singleton type?

[smarter]

This is explicitly disallowed since f0d3487 the commit message says:

Reason for 2) is that we can do a much better caching for eligible implicits if we can widen singleton arguments in ViewProto. This leads to consicderable speedups in implicit search which seem to be hard to get without the restriction.

But implicit conversions on singletons seem to be a common pattern, see for example:

• https://github.com/molecule-labs/molecule/blob/master/molecule-core/src/main/scala/molecule/stream/IChan.scala#L807
• https://github.com/scalameta/scalameta/blob/master/scalahost/src/main/scala/scala/meta/internal/hosts/scalac/converters/ToMname.scala#L36

We should either allow them or find a good replacement for them that can be automatized.

[odersky]

I have never seen that pattern before. Given that implicit conversions are anyway under a language flag, I don't think supporting this functionality is high priority.

[odersky]

The argument that this slows down implicit search has not been refuted. Closing for now, with scope to revisit if somebody can come up with a search algorithm that does not introduce slowdowns.

[allanrenucci]

Reopening as implicit conversion on singleton types is used a lot in the standard library. E.g.

implicit def toFactory[K <: AnyRef, V](dummy: AnyRefMap.type): Factory[(K, V), AnyRefMap[K, V]]
implicit def toBuildFrom[K <: AnyRef, V](factory: AnyRefMap.type): BuildFrom[Any, (K, V), AnyRefMap[K, V]]

cc/ @julienrf

[odersky]

For the new collections, it's easy to work around the restriction:

Make AnyRefMap extend a class AnyRefMapCompanion and use that class instead of AnyRefMap.type in the implicits.

[sjrd]

It is also a very common pattern in Scala.js facade libraries. You declare an @js.native object Foo with the JS API, then you pimp Scala-esque APIs on top of it using an implicit class for Foo.type.

In that case you cannot define the methods inside the object, because there can be only native methods in there. And you also do not want to alter the hierarchy because the facade types hierarchy should follow the JS hierarchy that it models. It's technically possible to extend from a dummy trait, but that's awkward.