Hello, I have an issue with kotlinjs. I tracked it...

# javascript

[eldc]

Hello, I have an issue with kotlinjs. I tracked it down to this code:

val s = run { p.toString() }
val p = 4
fun main() { println(s) }

It produces TypeError: p is undefined. When the first two lines are swapped, it works.

[konsoletyper]

It's expected behaviour

[eldc]

Really? It is a different behaviour than with Kotlin on JVM.

[eldc]

It also happens when the code is inside a object { ... }

[konsoletyper]

Yes, but in general behaviour will be the same. Java BE performs optimization for constants. In your case 4 will be set as an initial value for p, whereas s gets initialized in <clinit> section.

[konsoletyper]

Consider this:

val s = run { p.toString() }
val p = foo()
fun foo() = 4
fun main() { println(s) }

[eldc]

The code with foo() gives the same "p is undefined" error.

[eldc]

Oh, on the JVM it prints 0 instead of 4.

[eldc]

So it's not a flaw specific to the JS backend?

[konsoletyper]

What about this

val s = run { p.toString() }
val p: Any = foo()
fun foo() = 4
fun main() { println(s) }

[eldc]

NullPointerException

[konsoletyper]

I don't know. I just raised a question in internal JB chat whether this is a JVM-specific behavior or a part of language specification

[eldc]

Ok so the problem is at the langage level. If this code is not going to run correctly, I think it should fail at compile time, with unresolved reference: p

[konsoletyper]

I'm not sure

[konsoletyper]

The answer is no: it's not a problem in the language level. Even if we won't resolve p in the first line, it would be possible to write code like this:

fun foo() = p.toString()
val s: Any = run(::foo)
val p: Any = run { 42 }

fun main(args: Array<String>) { 
    println(s) 
}

[eldc]

I've just reproduced a similar issue with Scala. The problem must be very general.

[eldc]

A correct initialization order does not always exist.

[eldc]

The only way to prevent this kind of error would be by disallowing references to thing defined after -- just like if you wrap all the code into a fun() { ... }

[eldc]

But this is probably too restrictive.