Is there any know issue related to evaluation orde...

# eap

[Tomasz Krakowiak]

Is there any know issue related to evaluation order of delegated properties and other object's fields initialization expressions? I get "undefined" related errors when using properties that are delegated inside other field initialization expressions.

Edit: Turned the issue was caused by completely different bug.

Compare the result of:

fun main() {
    println(arrayOf("x")[1])
}

on JVM and JS - https://pl.kotl.in/OQW7p5XAL

I guess that's stdlib bug.

[ilya.gorbunov]

The behavior or Array.get when index is out of array bounds is platform-dependent: https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-array/get.html

[Tomasz Krakowiak]

@ilya.gorbunov Still... it violates method's signature by returning value of different type(undefined).

[ilya.gorbunov]

Yes, some bad things can happen in JS. The lesson here is that it's not a good idea to index arrays out of their bounds.

[Tomasz Krakowiak]

I believe this should be changed and behaviour should be consistent with JVM. When for performance reasons we want native JS array behaviour, the signature of get should be different (get(index : Int) : T*?*)

[Tomasz Krakowiak]

I mean... without any hacks we're getting value that doesn't satisfies expression type, which is... very bad. Kotlin is strongly typed, isn't it?

[ilya.gorbunov]

This is not the first case where values can be not satisfying the declared types in Kotlin: other examples are unchecked casts, leaking uninitialized instances. Kotlin is strongly typed to some practical degree.

[Tomasz Krakowiak]

Unchecked casts are checked at runtime.
For leaking uninitialized instance... eh, that's sad, but difficult to fix at this point.
But the arrays are actually easy to fix, but I agree now, that do not introduce unique flaw to the language.

[Tomasz Krakowiak]

btw. Ceylon used simple solution to prevent leaking uninitialized instances - https://ceylon-lang.org/documentation/1.2/tour/initialization/#initializer_section
https://ceylon-lang.org/documentation/1.2/tour/initialization/#circular_references

[Fudge]

Unchecked casts of type arguments are not checked at runtime.
E.g.

fun foo(x : List<Int>) {
    x as List<String> // Dangerous
}

[Tomasz Krakowiak]

Ah, that's due to type erasure. But when you retrieve value of type specified by type parameter, than a type check occurs.