Get rid of `= _` in variable definitions

[odersky]

An obscure use of _ occurs in var definitions:

var x: T = _

It defines a concrete variable x without an initial value, or rather the default initial value that the JVM assigns to object fields. It can only be used in a class or object, not to initialize a local variable. It is essential in situations like this:

new AbstractIterator[A] {
    private[this] var hd: A = _
    private[this] var hdDefined: Boolean = false
    ...
}

Here we cannot initialize hd with a value since its type is parametric, and we do not know a value for A. The logic in AbstractIterator makes sure that hd is read only after it is assigned by checking hdDefined before reading hd.

So the idiom is rare but essential where it is needed. But can we find a less obscure notation that does not add another overload to _?

One possibility would be to define somewhere an abstraction like this:

def defaultValue[T]: T = ...

defaultValue can be expressed in terms of _:

def defaultValue[T]: T = 
  object helper { var x: T = _  }
  helper.x

It can also be a compiler-intrinsic, and then it could replace = _ in variable definitions.

But I am a bit reluctant to do that, for fear that then defaultValue will be also used in situations where it is not appropriate. The big problem with defaultValue is that it returns null for all class types including boxed numeric types. That's very confusing! We do not want to give this a more prominent status than what we have. The situation would get worse with explicit nulls. In that case, we would have:

def defaultValue[T]: T | Null

But then

var x: T = defaultValue

would be ill-typed. It would have to be:

var x: T | Null = defaultValue

This is safe, but it defeats the purpose. What should happen for

var x: T = _

is that the programmer or the init-checker proves that x will be initialized with something else before it is first referenced. That's the intended meaning.

So, maybe a better choice is to re-use compiletime.erasedValue for this?

var x: T = erasedValue

This means there is no initial value at runtime (the value is erased), so there is no initial assignment. That can be allowed for objects and classes since objects are bulk-initialized (but the init checker should check that such variables are not referenced before being assigned to). It could be allowed in the future also for local variables if we can prove that the variable is initialized by assignment before use. Everywhere else erasedValue is illegal, by the current rules.

Admittedly, erasedValue is also obscure. However

• The whole thing is an obscure use case
• erasedValue can be looked up, unlike _
• erasedValue does not add to the confusion relative to the other uses of _.

[Katrix]

Isn't erasedValue a kind of weird fit for this in terms of looking it up? If I look up erasedValue currently, I get lot's of stuff about inline, match, and macros. As a user then, if I saw that when I was looking up this, I might think I took a wrong turn somewhere.

[sjrd]

As long as we're not targeting 3.0 with this change ... because this is not triggered by any feedback coming from the community, and we've already said that further language changes would only be done in response to community feedback. (Or blocking issues, which this is not since it's already an obscure use case, and as is, it works.)

[liufengyun]

the init checker should check that such variables are not referenced before being assigned to

I think it's generally not achievable without complicating things due to aliasing --- it's the same as enforcing a typestate protocol in a language.

On the other hand, if the object can be aliased, the usage of Option[T] might be safer for performance-insensitive applications:

- var x: T = _
+ var x: Option[T] = None

[odersky]

@Katrix The documentation of erasedValue would have to be changed to cover the new use case.

On the other hand, if the object can be aliased, the usage of Option[T] might be safer for performance-insensitive applications:

Yes, but the use case = _ is for performance sensitive applications. I believe it is OK to demand verification by hand that the variable is assigned before use.

[odersky]

Another choice would be to always use null as the initializer. I.e.

new AbstractIterator[A] {
    private[this] var hd: A | Null = null

But then the danger is that we will make use of the initial value since we went through the trouble of defining it:

   if hd == null then // initialize
   else // use hd, with flow typing we know it is not null

Very tempting but wrong, since null might be a legal value of type A. So, I believe _/erasedValue is better since they do not tempt one to test for null.

[liufengyun]

It seems to be at least in Dotty, var x: T = _ are all used in places where we know the concrete type of T. Therefore, such usage can be eliminated with either T | Null or a special sentinel value if T = Int.

In performance-sensitive applications, users can always use a cast to avoid runtime checks.

[odersky]

The example of AbstractIterator I gave comes straight out of the standard library. There are several others like that.

[odersky]

In performance-sensitive applications, users can always use a cast to avoid runtime checks.

I am not sure I agree. The point is, we want to communicate "this variable is defined but not initialized". That's a common idiom in all imperative languages. Making up a non-sensical initializer and then casting obscures the logic.

"

[sjrd]

I am not sure I agree. The point is, we want to communicate "this variable is defined but not initialized". That's a common idiom in all imperative languages. Making up a non-sensical initializer and then casting obscures the logic.

We already have to do that for local vars. We can do it for fields as well. There's nothing special about fields vs local vars in this. In fact I'm pretty sure I had to invent a non-sensical initializer for local vars more often than I have needed a = _ for fields.

[odersky]

Maybe compiletime.noValue instead of compiletime.erasedValue? That would avoid the confusion.

[LPTK]

Unless we can have a check that a variable is always initialized before accessing it (which seems hard to implement), leaving a variable uninitialized is a fundamentally unsafe way of programming, where the programmer basically tells the compiler "trust me on this".

So an unsafe cast seems warranted for this.

var hd: A = null.asInstanceOf[A]

Such a cast is similar in nature to the ones we need in the low-level implementations of things like ArrayBuffer (which needs casts because it's based on an underlying Array[AnyRef]).

Having a special feature like compiletime.noValue would make it look like using uninitialized variables is fine and dandy, legitimate even in non-performance-sensitive code, whereas it can actually lead to type soundness issues!

[odersky]

You can't write null.asInstanceOf[A] anymore, thankfully. We really need something that can be used for dropping initialization and nowhere else. So, how about

  var x: T = notInitialized

That's pretty clear, no? And it would get rid of the obscure use of _.

One can argue that notInitialized is unsound and therefore should not be used. I will not be the one to lead the battle to get rid of it in all existing code bases, but if someone else goes ahead, I am sympathetic.

[sideeffffect]

I know I don't bring much value with this, but still: As far as know (not only) in the Scala community, unsafe things are usually named unsafe*, so how about unsafeNotInitialized or unsafeUninitialized?
Maybe we don't need to get rid of this feature altogether, but naming it like this would clearly demarcate that the user is playing with fire here 🔥

[odersky]

unsafeNotInitialized would work as well, but i think notInitialized is probably sufficiently clear.