Introducing overloads in value classes no longer creates a binary incompatibilty with client code.

[retronym]

Prior to this change, the following linkage error could occur.

class C(val self: String) extends AnyVal { def foo = 1 }
object Test extends App { new C("").foo }

% scalac C.scala

% javap -cp /tmp 'C$'
Compiled from "62"
public final class C$ {
  public static C$ MODULE$;
  public static {};
  public final int foo$extension(java.lang.String);
...

class C(val self: String) extends AnyVal { def foo = 1; def foo(a: Any) = 2 }

% scalac C.scala

% javap -cp /tmp 'C$'
Compiled from "62"
public final class C$ {
  public static C$ MODULE$;
  public static {};
  public final int foo$extension0(java.lang.String);
  public final int foo$extension1(java.lang.String, java.lang.Object);
..
}

% && scala Test
java.lang.NoSuchMethodError: C$.foo$extension(Ljava/lang/String;)I
	at Test$.delayedEndpoint$Test$1(63:1)
	at Test$delayedInit$body.apply(63:1)

After this change, we no longer use the $0, $1, ... suffixes for overloaded methods, so we don't have the problem anymore.

[retronym]

Here's a followup after re-starring: https://github.com/retronym/scala/tree/topic/ext-method-overload-restarr

[lrytz]

I wonder why it wasn't done this way initially. 5118fd0d08

[retronym]

The SIP doesn't address overloading. Perhaps during Martin's WIP (before the commit to scala/scala) it was just based on "dead reckoning" to the corresponding name, and was then changed to a linear scan of the family of methods to "gain a level of insensitivity of how overloaded types are ordered between phases and picklings.".

Once you're doing that scan, you might as well just use overloading, which importantly extends this sensitivity to separate compilation

[adriaanm]

let's restarr before RC1 to get the full fix in

[dwijnand]

This avoids binary incompatibilities when adding/removing/reordering
overloaded methods in value classes.

I don't get the title or this description (and there are no test examples). Could someone give an example of what this change allows now? Thank you.

[retronym]

@dwijnand Thanks for the feedback, I've updated the title and description.

[dwijnand]

Ah, nice!! Thanks.

https://contributors.scala-lang.org/t/adding-overloads-to-value-class-breaks-binary-compatibility

[retronym]

I wonder why it wasn't done this way initially

@lrytz I asked @odersky last night. He told me the motivation for the suffixes was because Scala's overload resolution only uses the first parameter section, and in all cases that is the $this parameter.

$ scalac -Xprint:extmethods <(echo 'class C(val a: Any) extends AnyVal { def foo(a: Int) = 1; def foo(a: String) = 2 } ') | grep foo
    def foo(a: Int): Int = C.foo$extension0(C.this)(a);
    def foo(a: String): Int = C.foo$extension1(C.this)(a);
    final def foo$extension0($this: C)(a: Int): Int = 1;
    final def foo$extension1($this: C)(a: String): Int = 2;

This doesn't really matter in our implementation, because we create the C$.foo$extension selection with an explicit Symbol, rather than just using a Name and relying on Scala's overload resolution.