Thread: [Kotlin] Random Permutation

Originally Posted by Bartvh

I think the null-safety in Kotlin is probably one of its strengths. The fact that it is redundant doesn't matter. Every language has concepts that are redundant, but just make it easier for the developers.
This is the first time I heard about the for-operations/ranges issue. I tried some simple cases and couldn't find any evidence of this.

That's not true. Also, inline classes are experimental and will improve in 1.5.

[Only registered and activated users can see links. ]

Originally Posted by Velocity

you tell me, because it's now both a runtime AND a compile time problem, while on top the COMPILE-TIME part is applied in the runtime in the form of runtime throws (as if Java didn't do that already upon accessing a null??)

Pretty sure the runtime overhead they add for NPE is translating stack traces back to Kotlin source code. Which is fine by default, but give me a switch for that. I can figured out where my kotlin code went wrong based off a Java stack trace without the added runtime overhead.

And if the compile time checking is as reliable as Scu implies, why the need for the runtime overhead at all?

Originally Posted by Bartvh

Why are you posting this? This issue was fixed almost 3 years ago.

Because if you look the parent issue is still open with multiple sub tickets regarding basic for loop optimization.

Originally Posted by Velocity

you tell me, because it's now both a runtime AND a compile time problem, while on top the COMPILE-TIME part is applied in the runtime in the form of runtime throws (as if Java didn't do that already upon accessing a null??)

Actually, you can turn them off "-Xno-param-assertions" and "-Xno-call-assertions"

Edit also "-Xno-receiver-assertions"

[Only registered and activated users can see links. ]