Treatment of uninitialized vars

[abeln]

When we write var s: String, s is "initialized" to null. Do we want to force the user to declare s as var s: String|Null in these cases?

[liufengyun]

In the safe init prototype, it produces warning for such uninitialized fields.

[olhotak]

Do you mean var s: String = _ ? Without the _ initializer, isn't it just an abstract var that is required to get an initializer in a subclass?

[liufengyun]

Yes, you are correct @olhotak , it only produces warnings for var s: String = _.

[abeln]

@olhotak Yes, I meant var s: String = _

But not only in fields, also as a local variable. i.e. should the following be allowed?

def foo() = {
  var x: String = _
}

[abeln]

@olhotak @liufengyun

Should we disallow

def foo() = {
  var x: String = _
}

i.e. _ in local definitions?

It seems to me the answer should be yes, because there's no longer a "default" value for a String reference. The user can always declare the field nullable if they want a default value.

def foo() = {
  var x: String|Null = _
}

[abeln]

So the rule seems to be:

var x: T = _

is allowed only if either 1) T it not a reference type 2) T is a reference type where Null <: T (e.g. T = String|Null)

[liufengyun]

@abeln Your last comment makes perfect sense to me.

[olhotak]

I agree too.

On Mon, Dec 17, 2018 at 10:35:48PM +0000, Fengyun Liu wrote:

@abeln Your last comment makes perfect sense to me.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.*

[abeln]

We've reversed course on this. For now, we decided to allow "_". The rationale is allowing the user to express that a field or local variable is non-null but the initialization logic in non-trivial (i.e. as an escape hatch).