I have a question about constructors in Kotlin. Let's assume the following code: ```interface Base ...

# getting-started

[dirk.dittert]

I have a question about constructors in Kotlin. Let's assume the following code:

interface Base {
	val number: Int
}

class SomeClass: Base {
	override var number: Int
		private set
		
	init {
		number = 42
	}

}

This results in an error: Property number must be initialized. I did not expect this as the documentation says that the code in the init block effectively becomes part of the primary constructor.
There seems to be a workaround by changing the init block to:

constructor() {
    number = 42
}

But that's something inspections don't like so much (secondary constructor should be converted to primary constructor).

Is this intended behaviour?

[Matteo Mirk]

Why is it val in the interface but var in the concrete class? Also, why do you need it to be mutable only privately, is it intentional?

[dirk.dittert]

This is a distilled down example. Clients code against the interface Base and that provides only read only access. Internally, there can be setters for properties as well (as in my example here)

[Matteo Mirk]

I see thanks

[dirk.dittert]

And: Kotlin is fine with the code if the implementation class also declares the property as val (in combination with an init block).

[Matteo Mirk]

yeah I tried that locally, so that’s why I asked if it was necessary to have it var but with private setter 🙂

[dirk.dittert]

Yes, it is necessary.

[ephemient]

override var number: Int = 42
    private set

is it not possible to initialize normally?

[dirk.dittert]

The value was generated dynamically in the constructor of the class. In this case by reading environment variables.

[ephemient]

in that case you still have an ugly workaround,

override var number: Int = 0
    private set
init {
    number = 42
}

[ephemient]

oh, another option is

final override var number: Int
    private set
init {
    number = 42
}

[ephemient]

essentially, Kotlin does not want the uninitialized backing field to ever be observable, but if the property is open, then that can't be guaranteed

[ephemient]

so it either must be initialized in a way that doesn't go through an overridable setter (e.g. override var number: Int = 42 initializes the field directly), or the setter must not be overridable (as a subclass could then observe the uninitialized state)

[ephemient]

although I do see an argument that this being confusing given that the class itself is not open, but that's a different issue…

[dirk.dittert]

I think, my issue with this is, that Kotlin seems to be fine if the property is initialized in a secondary constructor but not in an init block.

[ephemient]

init blocks are run along with property initialization in declared order, whereas a constructor is run last, after super constructor has been called