Hi, I was wondering if this is a known issue already or I should file one. I expect the program belo...

# compiler

[raulraja]

Hi, I was wondering if this is a known issue already or I should file one. I expect the program below to not compile because the expression A.B.c can’t be resolved until A is initialised assuming the inner object is path dependent. If the object is not and it’s fully static then s should not have compiled or become accessible.

Untitled

[dmitriy.novozhilov]

Compiler don't (and won't) analyze order of initialization because it's a very complicated (Turing-complete actually) problem, and implementing it may dramatically decrease compiler performance

[dmitriy.novozhilov]

For such analysis in common case compiler should evaluate whole program to approve that there is no execution ways which may lead to such errors on runtime

[dmitriy.novozhilov]

You can get NPE in a much simpler case with leaking this during class initialization:

class A {
    val x: String

    init {
        printX()
        x = ""
    }

    fun printX() {
        println(x.length)
    }
}

fun main() {
    A()
}

[dmitriy.novozhilov]

And another:

val x: String = y

val y: String
    get() = x

fun main() {
    println(x.length)
}

[kralli]

@raulraja I think you were led astray by using the letter s twice in you example. c is referencing the top-level s , not the s in the constructor of A .

class A(val s: String) {
    object B {
        val c: String = d
    }
}

val d: String = A.B.c

fun main() {
    println(d) //s is null
}

[raulraja]

yep, thanks @kralli

[raulraja]

and that makes me feel a lot better 😅