Make Null a subclass of AnyVal under -Yexplicit-nulls

[sjrd]

@tarsa

in other words, null is mainly for interop with java.

[…]

if we use null-infested java api from scala, then we need to know how java uses nulls anyway, so having a scala null that works very differently from java null is counterproductive here

You can make the same argument about JavaScript. And in JavaScript, null has type Null which is considered a primitive type.

@robstoll

For me explicit-null should enable that NPEs are thrown as early as possible i.e. at the boundary, without me needing to insert nn.

No. Explicit-nulls should make it so that no NPEs are thrown at all In the same way that our existing type system ensures that no ClassCastExceptions are thrown at all (as long as one doesn’t perform an incorrect asInstanceOf/nn, as usual).

@robstoll

More as a side question. This change is not a binary break, neither a source (all programs still compile), but it is a behaviour change which can break programs.

This change is only proposed in the context of -Yexplicit-nulls, which is experimental. Therefore, breaking changes don’t count.

@robstoll

def foo[T <: AnyVal]

It seems I need to repeat this every 10th reply: if you don’t provide a concrete use case for a T <: AnyVal bound, it’s not worth discussing what would happen to such code.

@Sporarum

1. Do Proposal: Fixing null.methodOfAny() under explicit-nulls (without Null <: AnyVal): null is less of a footgun (not a footgun anymore ?) and we preserve the ability to exclude it from generics => no possible loss wrt interop
2. Make Null <: AnyVal and add NonNull, makes null even more normal, and we preserve same capability wrt interop
3. Remove NonNull once we show that it is not useful anymore, either because it never was, or because we added feature(s) tailored to better suiting what it was useful for

Or: don’t add NonNull. Wait and see if it’s actually missing before introducing it → no backward compat lockdown.

@tarsa

the proposal from this thread is a net downgrade from technical perspective for scala users. it:

• worsens java interop
• prevents straightforward implementation of nonnull type

It turns out this is not true. There is already no straightforward way to implement NonNull. See "MINUS_NULL" and the future of explicit nulls - #25 by sjrd . And therefore, it can’t be argued that it will worsen Java interop.