Null and singletons cause inconsistencies

[s5bug]

Compiler version

3.1.1, 3.1.2

Example 1:

Transitivity of subtyping is violated:

val fredToFredOrWilma: "Fred" <:< ("Fred" | "Wilma") = summon

val nullToFred: Null <:< "Fred" = summon

val nullToFredOrWilma: Null <:< ("Fred" | "Wilma") = summon // errors

Output

no implicit argument of type T was found for parameter x of method summon in object Predef

where:    T is a type variable with constraint <: Null <:< (("Fred" : String) | ("Wilma" : String))

Expectation

Either:

1. nullToFred fails
2. <:< is transitive and Null <:< "Fred" <:< ("Fred" | "Wilma")

Example 2:

scala> val x: "Fred" = null
val x: "Fred" = null 
scala> x
val res1: String = Fred // notice this is not `null`!

Expectation

Either:

1. null is not assignable to a "Fred"
2. x reports a value of null

Example 3:

Null is accepted for variable .types but not object .types (which are both nullable in the JVM):

scala> val foo: Int = 1
val foo: Int = 1

scala> val fooNull: foo.type = null
-- [E007] Type Mismatch Error: -------------------------------------------------
1 |val fooNull: foo.type = null
  |                        ^^^^
  |                        Found:    Null
  |                        Required: (foo : Int)

longer explanation available when compiling with `-explain`
1 error found

scala> val bar: String = "bar"
val bar: String = bar

scala> val barNull: bar.type = null
val barNull: bar.type = null

scala> object baz
// defined object baz

scala> val bazNull: baz.type = null
-- [E007] Type Mismatch Error: -------------------------------------------------
1 |val bazNull: baz.type = null
  |                        ^^^^
  |                        Found:    Null
  |                        Required: baz.type

longer explanation available when compiling with `-explain`
1 error found

Expectation

Either:

1. null should not be accepted as an inhabitant of bar.type
2. null should be accepted as an inhabitant of baz.type

Example 4:

Unions of two singletons don't accept null, but not a union of a singleton and a non-nullable:

scala> val f: "Foo" = null
val f: "Foo" = null

scala> val g: ("Foo" | 1) = null
-- [E007] Type Mismatch Error: -------------------------------------------------
1 |val g: ("Foo" | 1) = null
  |                     ^^^^
  |                     Found:    Null
  |                     Required: ("Foo" : String) | (1 : Int)

longer explanation available when compiling with `-explain`
1 error found

scala> val h: ("Foo" | Int) = null
val h: "Foo" | Int = null

scala> val i: ("Foo" | "Bar") = null
-- [E007] Type Mismatch Error: -------------------------------------------------
1 |val i: ("Foo" | "Bar") = null
  |                         ^^^^
  |                         Found:    Null
  |                         Required: ("Foo" : String) | ("Bar" : String)

longer explanation available when compiling with `-explain`
1 error found

Expectation

Either:

1. The declarations for f and h are invalid
2. The declarations for g and i are valid

---

If Scala 2 behaviors are wanted to be kept, then the proper path is taking the (2.) options.

However, if (2.) is taken, it means that any AnyRef & Singleton will actually have two values, not one.

[rmgk]

I just want to add another inconsistency related to the conversion from null to a string singleton type:

scala> def f(a: "A"): a.type = a
def f(a: "A"): a.type
                                                                                                                                                   
scala> f(null)
java.lang.ClassCastException: class java.lang.String cannot be cast to class scala.runtime.Null$ (java.lang.String is in module java.base of loader 'bootstrap'; scala.runtime.Null$ is in unnamed module of loader java.net.URLClassLoader @3c1e23ff)
  ... 31 elided

To me it seems that (null: "A") should simply not be valid to make string singleton types consistent with all other singleton types.

[olhotak]

I checked that with -Yexplicit-nulls, options (1.) are taken in all the examples.

Perhaps we could take options (2.) always without -Yexplicit-nulls for compatibility with Scala 2, and require -Yexplicit-nulls for options (1.) (i.e. for null-correctness).

[mbovel]

Related discussion in #3958

[s5bug]

As of 3.5.2:

1. option (1) is taken in Example 1: Null <:< "Fred" does not hold
2. option (1) is taken in Example 2: null: "Fred" is invalid
3. option (2) is taken in Example 3: null: someString.type and null: SomeObject.type both hold
4. option (1) is taken in Example 4: null: "Foo and null: ("Foo" | Int) are both invalid

All of these are consistent individually now, but Example 3 is inconsistent with the others.

[sjrd]

x.type is null able by (broken) spec.

The spec and the behavior were adjusted under explicit nulls.