Ugh implicit value classes

[travisbrown]

If we've got the following set-up:

import io.circe._, io.circe.optics.JsonPath.root, io.circe.syntax._

val json = Map("a" -> Map("b" -> Map("c" -> 1))).asJson
val path = root.a.b.c.as[Int]

And then we try to use the Optional, we'll get this:

scala> path.getOption(json)
res0: Option[Int] = None

scala> path.modify(_ + 1)(json)
res1: io.circe.Json =
{
  "a" : {
    "b" : {
      "c" : 1
    }
  }
}

But…

scala> root.x.y.z.as[Int].getOption(Map("x" -> Map("y" -> Map("z" -> 1))).asJson)
res2: Option[Int] = Some(1)

This made absolutely no sense to me for about ten minutes this morning, until I remembered that the io.circe.syntax.EncoderOps class looks like this:

implicit class EncoderOps[A](val a: A) extends AnyVal {
  def asJson(implicit e: Encoder[A]): Json = e(a)
}

Which means that anything with an Encoder instance gets a a method that's just the identity. For some reason I never realized that implicit value classes have this horrible property. This happens in the standard library, too. For example, in a fresh REPL:

scala> 13.self
res0: Int = 13

…thanks to RichInt. I hate implicits.

At the moment I can imagine three solutions:

1. Make EncoderOps not a value class.
2. Give the value member a more obfuscated name that isn't likely to result in collisions.
3. Introduce a dummy class with a method name that intentionally collides.

I'm leaning toward the first option.

[xuwei-k]

or drop Scala 2.10 support?

• scala/scala@4595ac6
• scala/scala@e2a3498

[travisbrown]

Thanks, @xuwei-k. There are at least a couple of other places where we have workarounds for 2.10—maybe it's time for version-specific source trees.

[fthomas]

Note that Scala.js currently does not look into shared/src/main/scala-$VERSION directories (see scala-js/scala-js#2005) so you would have to duplicate some files across js and jvm directories.

[chwthewke]

Sorry for kind of barging in (saw @travisbrown 's tweet), but wouldn't making the field private (class FooOps(private val a: A) extends AnyVal etc.) be a viable fourth solution? It does seem to properly hide the a method.

[travisbrown]

@chwthewke That works on 2.11, but not 2.10, unfortunately.

[chwthewke]

@travisbrown Gotcha, thanks for the explanation

[propensive]

I don't think option 2 is a bad choice. It would be consistent with the common approach of giving implicit values long, descriptive names to avoid likely clashes.

[ghost]

Note that Scala.js currently does not look into shared/src/main/scala-$VERSION dir....

Or copy https://github.com/InTheNow/sbt-catalysts/blob/master/src/main/scala/sbtcatalysts/CatalystsPlugin.scala#L156-L172

(Or... just use sbt-catalysts)