class Age(var second: Int) {
var age: Int = 4
val isYoung // backing field is not generated.
get() = age < 30
// var isYoung // why is backing filed generated automatically here?
// get() = age < 30 // Property must be initialized
}
Before I asked this question I read a similar question, but I still have a question.
The Backing Fields docs mention the following two cases in which a backing field is generated:
- when property uses the default implementation of at least one of the accessors.
- when a custom accessor references it through the field identifier.
Both the question on the link and my question are custom accessors, so it’s probably case 2.
My question is, the document clearly states that it is created if the custom accessor refers to the backing field through the field identifier. But why does the answer in the link say that it is created by default in the var?
I still can do val but I didn’t understand exactly why var can’t.
No, it is case 1 “property uses the default implementation of at least one of the accessors“: You only use a custom get accessor, you don’t use a custom set accessor. Therefore the default implementation is used for it and the condition of 1. is satisfied.
Look at it this way: If you change the property from val to var you can now do something like this:
age.isYoung = false
Without a custom set, what do you expect to happen now? where is false stored, what should be its impact?
The answer is that Kotlin automatically creates a backing field to store that value. And if there is such a field, then it also must be properly initialized, hence the compile error.
You might think that that field is irrelevant because it isn’t used anywhere: isYoung will always be age < 30, independent of what it was set to (like false, see above). Well, in your specific case it is indeed useless, but then you should make the property val to prevent it from being settable in the first place. Why allow a value to be set that is never used?
But what if you do want to use the backing field’s value?
var isYoung // wont compile without initializer
get() = field || age < 30
And now you see why it is important to have the initializer. Otherwise the calculation field || age < 30 wouldn’t be possible.