Erase Int | Nothing signatures types into Int

[nicolasstucki]

Aligns | Nothing with & Any and Nothing | with Any & for value types.

This also fixes summon[ClassTag[Int | Nothing]] as it is now equivalent to summon[ClassTag[Int]].

This applies to all value types.

Fixes #14970
Fixes #14964

⚠️ This is a binary breaking change ⚠️

the Previous version generated the def f: Int and def f: Object variants of the method.
In the new one, we only generate the def f: Int version.
Unfortunately, the previous version called the boxed version of the interface that does not exist anymore.

Is this something that we encounter in practice?

[nicolasstucki]

As far as I can see, the Int | Nothing pattern should not appear in any user code. If this is the case then changing it should not impact signatures in real code. It will impact the ClassTag by fixing cases that were buggy.

I would argue that this erasure is a bug and should be fixed. If a library accidentally used this and cares about binary compatibility, they can add the bridge themselves.

[sjrd]

they can add the bridge themselves.

I don't think that's possible. How would they do that? It would result in an ambiguous overload, wouldn't it?

[nicolasstucki]

they can add the bridge themselves.

I don't think that's possible. How would they do that? It would result in an ambiguous overload, wouldn't it?

Indeed, it is not possible 😞

[smarter]

You can avoid ambiguous overload errors by relying on @targetName:

import scala.annotation.targetName
class A:
  def foo: Int = 1
  @targetName("foo") def fooBinCompat: Any = 1

[smarter]

... but that's not good enough for library authors in general as a workaround to binary compatibility breakages, because their methods might be overrridden in user code as @sjrd pointed out last time I wanted to break binary compatibility 😬

[nicolasstucki]

Then the real question is if there are libraries that use these types in their signatures.

[odersky]

I think this logic has gotten a bit messy and can be simplified. Why not:

if tp1.isRef(defn.NothingClass)
    || tp1.isRef(defn.NullClass) && tp2.derivesFrom(defn.ObjectClass))
then return tp2

And the same to return tp1.

[odersky]

I would hope that A | Nothing would not normally appear in library code. The current behavior looks wrong since it violates the property that erasure(A | B) = erasure(B) if A <: B.

So I'd tend to go ahead with merging this after the logic is made clearer.

[smarter]

You can avoid ambiguous overload errors by relying on @TargetNAME:

By the way, even if this works around (some) binary-compatibility issues, it can also break tasty-compatibility since we refer to methods by their original names there.

[nicolasstucki]

The current behavior looks wrong since it violates the property that erasure(A | B) = erasure(B) if A <: B

I believe it is not violated. With the current behavior, Int | Nothing and Nothing | Int erase to Int.

• erasure(Int | Nothing) = erasure(Nothing) if Int <: Nothing the guard does not hold
• erasure(Nothing | Int) = erasure(Int) if Nothing <: Int the guard holds and we have the correct erasure

Similarly for erasure(A | B) = erasure(A) if B <: A.

[nicolasstucki]

Apart from signatures and ClassTags is there something else that uses erased lub?

[dwijnand]

LGTM

[nicolasstucki]

Based on #14998, the only Nothing | T erasedLub is for Nothing | Null which used to erase to Object and still erases to Object.

[smarter]

Breaking binary compatbility likes this sets a bad precedent. Is the current behavior really fundamentally broken or merely inconvenient?

[nicolasstucki]

Breaking binary compatbility likes this sets a bad precedent. Is the current behavior really fundamentally broken or merely inconvenient?

As far as I can see it is only fundamentally broken for the ClassTag use case. It seems that the signature side only causes unnecessary boxing. I will investigate further to see if I can find a situation where the signatures break something.

We could do an alternative fix for #14964 that would make the erased lub behave differently if we are computing the erased type for a ClassTag.

[smarter]

Actually you don't even need ClassTag to run into issues:

object Test {
  def main(args: Array[String]): Unit = {
    val x: Array[Int | Nothing] = Array()
    val y: Array[Int] = x
  }
}

Exception in thread "main" java.lang.ClassCastException: [Ljava.lang.Object; cannot be cast to [I
        at Test$.main(arri.scala:3)
        at Test.main(arri.scala)

So yeah, I guess the erasure of union types is just fundamentally broken which would justify changing it :/. If we do change it in 3.2, we could warn in 3.1.3 about any code that relies on it to ease migration.

[odersky]

LGTM

[bishabosha]

this will also break backwards tasty compatibility of resolving methods by their signature