For a Kotlin line like: ```_localctx!!.value = _localctx.exp!!.value ``` where `_localctx!!` reports...

# javascript

[Edoardo Luppi]

For a Kotlin line like:

_localctx!!.value = _localctx.exp!!.value

where _localctx!! reports a UNNECESSARY_NOT_NULL_ASSERTION

K/JS will still output:

ensureNotNull(_localctx).value_1 = ensureNotNull(_localctx.exp_1).value_1;

Worth opening an issue for an optimization?

[Vampire]

It is just a warning and the compiler could be wrong.
I guess if you as developer decide to do the maybe unnecessary null-check, the compiler should just follow suite as it does.

[Edoardo Luppi]

@Vampire I'd be of the same opinion, but in the outputted JVM bytecode there is no trace of null checks where UNNECESSARY_NOT_NULL_ASSERTION is present.

[Edoardo Luppi]

So looks like a missing optimization on the JS side

[Artem Kobzar]

I feel that we can pass this information from the front end through the compilation and on the codegen know about such a thing. Do you know if the behavior is the same for K1 and K2?

[Edoardo Luppi]

I'll try with K2 and let you know!

[Vampire]

Oh, ok, inconsistent behavior is bad of course. 🙂

[Edoardo Luppi]

@Artem Kobzar same with K2

[Edoardo Luppi]

I'll try with a small reproducer, just to check if it happens always

[jw]

I would prefer if the JVM bytecode were fixed to emit the explicit null check (and native/wasm too).

This fits in where you can still safe call ?. or null check something that the compiler thinks is non-null and it will emit the conditional. When Java libraries are incorrectly annotated this is a lifesaver.

[Edoardo Luppi]

Yeah I get what you're saying. Mmm, in my case I'd love to get the optimization because the more performance I can get, the better it is.

[Edoardo Luppi]

I guess instead of this optimization, I could go down this route (when/if it will be available) https://youtrack.jetbrains.com/issue/KT-64125