I tried to find a discussion of this, so forgive me if this has been addressed. When defining a class, what was the reason that nullable properties are not, by default, simply set to null?
class SomeClass {
var name: String?
}
This will not compile because it requires the name to be assigned.
class SomeClass {
var name: String? = null
}
This is coming up because I’m using some OR libraries, and they tend to require accessible attributes that are set after the object is constructed, so they have to be nullable. But having to set them all to equal null, while not a huge deal, clutters up the code quite a bit, and I’m not (yet) understanding why they can’t be initialized to null by default.
I guess maybe then this is a broader question then... if a var is nullable, what is the harm of initializing the value to null when there is no other initialization? I would apply this even to local variables as well. For me, this furthers the goal of cleaning up and reducing the verbosity of the language:
class X {
var x: String? // initialized to null
val y: String? // initialized to null. This could raise a warning, but not important because an error will occur if attempt to assign this value later
var z: String // illegal, error
var a: String? = "sometext" // as current
var b: String? = null // same as var x:String?
fun do() {
var x: String? // intialized to null
val y: String? // warning, since setting this to null is not likely what you want
}
}
One of the goals of the project is to “make it more concise than Java”, and it feels to me like this furthers that goal without much downside.
Conciseness works also on concept than just mere typing. Right now the rule of "any properties, val or var, must be initialized, without exception" is much more concise than the three or four possible path to properties declaration.
But wouldn't that also apply to variable types? The language doesn't require you to always specify a type for a variable... it allows you to drop the type when that type can be inferred.
I read ‘concise’ to imply that the language ought not require a human to write something that can be reasonably inferred otherwise, unless that inference is something dangerous. In this case, the language can easily infer a null value, and there’s nothing particularly dangerous about that.
The one caveat here is that I understand the design is ‘conservative’, and in this case, requiring null is more conservative. If the rule was relaxed to infer null at a later time, it wouldn’t break code, whereas the opposite would not be true. That said, I’d still suggest the change.
The rule for variable declaration is consistent: anything local or private member can be inferred, anything protected or public must be specified.
I agree with your point that the design is conservative and I don’t mind it. The primitives for example could have been assigned default value like in C# to shorten typing.