Compiler does not error when duplicate methods exist in generated bytecode

[kubukoz]

Compiler version

3.3.1

Minimized code

//> using scala 3.3.1

case class StaticBinding(v: String) {
  private def copy$default$1(): String = ???
}

object Demo extends App {
  val b = StaticBinding("test")
  println(b)
}

Output

Error: Unable to initialize main class Demo
Caused by: java.lang.ClassFormatError: Duplicate method name "copy$default$1" with signature "()Ljava.lang.String;" in class file StaticBinding
Program exited with return code 1.

Expectation

Compilation failure (same as in 2.13.11):

[error] ./main.scala:3:26
[error] double definition:
[error] private def copy$default$1(): String at line 4 and
[error] def copy$default$1: String at line 3
[error] have same type
[error] case class StaticBinding(v: String) {
[error]                          ^
Error compiling project (Scala 2.13.11, JVM (17))

[som-snytt]

Noticed at erasure in Scala 2. The error makes me appreciate nicely formatted messages, as well as informative ones.

[soronpo]

User code is not supposed to have names with $ in them.

[kubukoz]

User code is not supposed to have names with $ in them.

Then it should at least be a warning ;) is this documented somewhere? I've seen a similar comment before, but it seems like an unwritten (or at least not loud and enforced) rule.

For context, I was trying to do this to keep binary compatibility after a parameter type change in a case class. Isn't this a legitimate thing to do as a library author trying to avoid breaking changes?

[som-snytt]

@kubukoz yes, no dollars is at the beginning of the spec, not obscure at all. That's not only to avoid collisions, but I assume also to avoid anyone relying on an implementation detail.

Your use case is interesting, like "can I break the law if it's to keep someone from breaking the law?" There is even something selfless and noble about it.

Edit: I don't know why there is no lint for dollars in identifiers, or an import scala.language.dollars.