L'inizializzazione della variabile di Kotlin per la classe figlio si comporta in modo strano per l'inizializzazione della variabile con valore 0

Ho creato la seguente gerarchia di classi:

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)
}

L'output di questo codice è

Hello World!!
x in f: 1
x: 33
x2: 33
in main x : 33

Ma se cambio l'inizializzazione di xda

var x: Int = 33

per

var x: Int = 0

l'output mostra l'invocazione del metodo in contrasto con l'output sopra:

Hello World!!
x in f: 1
x: 1
x2: 1
in main x : 1

Qualcuno sa perché l'inizializzazione con 0causa un comportamento diverso rispetto a quello con un altro valore?

la superclasse viene inizializzata prima della sottoclasse.

La chiamata del costruttore di B chiama il costruttore di A, che chiama la funzione f stampando "x in f: 1", dopo che A è inizializzato, il resto di B viene inizializzato.

Quindi, essenzialmente, l'impostazione del valore viene sovrascritta.

(Quando inizializzi le primitive con il loro valore zero in Kotlin, tecnicamente non si inizializzano affatto)

È possibile osservare questo comportamento di "sovrascrittura" modificando la firma da

var x: Int = 0 per var x: Int? = 0

Poiché xnon è più la primitiva int, il campo viene effettivamente inizializzato su un valore, producendo l'output:

Hello World!!
x in f: 1
x: 0
x2: 0
in main x : 0

Questo comportamento è descritto nella documentazione - https://kotlinlang.org/docs/reference/classes.html#derived-class-initialization-order

Se una di queste proprietà viene utilizzata nella logica di inizializzazione della classe di base (direttamente o indirettamente, attraverso un'altra implementazione di membro aperto sovrascritta), può portare a un comportamento errato o a un errore di runtime. Quando si progetta una classe di base, è pertanto necessario evitare di utilizzare membri aperti nei costruttori, inizializzatori di proprietà e blocchi init.

UPD:

C'è un bug che produce questa incoerenza - https://youtrack.jetbrains.com/issue/KT-15642

Quando una proprietà viene assegnata come effetto collaterale di una chiamata di funzione virtuale all'interno del super costruttore, il suo inizializzatore non sovrascrive la proprietà se l'espressione dell'inizializzatore è il valore predefinito del tipo (null, zero primitivo).