Imported From: https://issues.scala-lang.org/browse/SI-1470?orig=1
Reporter: @DRMacIver

@lrytz said:
Postponed until we know more about non-nullable types. The problem also appears in other situations, e.g.

var x: AnyVal = _

@SethTisue said (edited on Sep 3, 2016 12:18:51 AM UTC):
huge 2016 thread on this at https://groups.google.com/d/msg/scala-user/VRmZ-XrFr0U/zFWJKUovBgAJ . most of the thread is about shenanigans involving asInstanceOf, but you don't actually need asInstanceOf to get into trouble.

one of the "other situations" Lukas mentions is with generic types:

scala> class Sloppy[A] { var value: A = _ }
defined class Sloppy

scala> new Sloppy[Double].value
res14: Double = 0.0

scala> new Sloppy[Double].value: Any
res15: Any = null

scala> new Sloppy[Double].value: AnyVal
res16: AnyVal = null

scala> println(new Sloppy[Double].value)
null

@SethTisue said:
maybe we should just deprecate this = _ thing. the only time it means something you can really count on is for AnyRef types, in which case you might as well write = null, rather than sneak a null into your program without actually writing "null" into the source. and if someone wants the Any/AnyVal behavior they can always write = null.asInstanceOf[T], raising explicit two red flags right there in the source — again, less sneaking.

@soc said:
I'd rather wait a bit until we know what we can expect from Java 10 in the future. Maybe it will make things easier, maybe not.

Oliver Ruebenacker (curoli) said:
Specialization changes the behavior:

object GenInitApp extends App {

class Unspecialized[T] { var x: T = _ }
class Specialized[@specialized(Float) T] { var x: T = _ }

println("Unspecialized x is " + (new Unspecialized[Float]).x)
println("Specialized x is " + (new Specialized[Float]).x)

}

Output is:

Unspecialized x is null
Specialized x is 0.0

@som-snytt said (edited on Sep 10, 2016 6:33:35 AM UTC):
Without default value syntax, you can't distinguish default value from "reset".

var x: String = if (x == null) null else x  // don't munge early setting

I was just looking at a field that was side-effected from early definition, so the explicit definition would have to be early, too, and not just earlier in the template body.

The comment on the warning:

bq. val bar: X = bar, which come up more frequently than you might think.

Adding two cents here: deprecating the val x = _ notation won't be enough, because the problem is also triggered when calling Java parametric classes from Scala. Take this Java class:

public class Producer<A> {
    A get() {
        return null;
    }
}

And call it from Scala:

  val p = new Producer[Boolean]
  val bool = p.get()
  println(bool) // prints "false"
  println(bool.getClass) // prints "boolean"
  println(p.get()) // prints "null"
  println(p.get().getClass) // prints "boolean"

@gaelrenoux Starting Scala 3 Dotty, it will actually be a non issue. A variable cannot be assigned to null unless the type is a union type with Null. So in your example, returning null as A is illegal in Scala. As for Java interface, all values from Java library output is implicitly a union type with Null.

Expected type of Any says no unboxing of null:

scala> class C[A] { def get: A = null.asInstanceOf[A] }
defined class C

scala> new C[Boolean].get
res0: Boolean = false

scala> new C[Boolean].get: Any
res1: Any = null