Kotlin variable initialization for child class behaves weird for initializing variable with value 0

I have created the following class hierarchy:

```Kotlin
open class A {
init {
f()
}

open fun f() {
println("In A f")
}
}

class B : A() {
var x: Int = 33

init {
println("x: " + x)
}

override fun f() {
x = 1
println("x in f: "+ x)
}

init {
println("x2: " + x)
}
}

fun main() {
println("Hello World!!")
val b = B()
println("in main x : " + b.x)
}
```
The output of this code is
```lang-none
Hello World!!
x in f: 1
x: 33
x2: 33
in main x : 33
```

**But** if I change the initialization of `x` from
```Kotlin
var x: Int = 33
```
to
```Kotlin
var x: Int = 0
```
the output shows the invocation of the method in contrast to the output above:
```lang-none
Hello World!!
x in f: 1
x: 1
x2: 1
in main x : 1
```
Does anyone know why the initialization with `0` causes a different behaviour than the one with another value?

super class is initialized before sub class.

The constructor call of B calls the constructor of A, which calls the function f
printing "x in f: 1", after A is initialized, the rest of B is initialized.

So essentially, the setting of the value is being overwritten.

(When you initialize primitives with their zero value in Kotlin, they technically just dont initialize at all)

You can observe this "overwrite" behavior by changing the signature from

`var x: Int = 0` to `var x: Int? = 0`

Since `x` is no longer the primitive `int`, the field actually gets initialized to a value, producing the output:
```
Hello World!!
x in f: 1
x: 0
x2: 0
in main x : 0
```

This behavior is described in the documentation —

[To see links please register here]

>
If any of those properties are used in the base class initialization logic (either directly or indirectly, through another overridden open member implementation), it may lead to incorrect behavior or a runtime failure. When designing a base class, you should therefore avoid using open members in the constructors, property initializers, and init blocks.

UPD:

There is a bug that produces this inconsistency —

[To see links please register here]

>When a property is assigned as a side-effect of a virtual function call inside the super constructor, its initializer does not overwrite the property if the initializer expression is the type default value (null, primitive zero).