Hi all, today I noticed that there are no null che...
# javascript
l
Hi all, today I noticed that there are no null checks for non nullable fields for generated JS code in KMP. I was assuming that the behaviour might have been similar to JVM where generated bytecode has null checks and code fails fast but it is not. How do people overcome this usually ? I can manually add null checks in
init {}
block but not only kotlin gives warning for that, it's cumbersome process to add to all exposed classes and would pollute the code as well.
e
If the compiler can guarantee those values will never be null, it makes little sense to add runtime checks, which would also slow down the code path.
s
That is only true if generated code is not consumed by javascript. In our case we generate a library used by js devs, and these missing checks makes the code break at unexpected places. And also going by what you said @Edoardo Luppi , runtime checks shouldn’t have been added in generated byte code too which isn’t the case. There is mismatch in behaviour for code generated for jvm targets and js targets.
e
You can remove most null check intrinsics under the JVM backend with a couple of additional compiler options. The JS environment requires trade offs to have an acceptable performance. By your metric we should also have array bounds checking at each index access, which we don't have for the aforementioned reason.
s
My metric was just that behaviour is similar across targets unless explicitly documented :), otherwise will be surprising for most folks
2
To achieve parity in the case here, we will have to litter our code with not null checks (and disable the useless condition warning), quite cumbersome
c
> By your metric we should also have array bounds checking at each index access, which we don't have for the aforementioned reason. Bounds are checked for ArrayList, which is what 99% of users should be using. If arrays were needed more often, I would be in favor of bound checking for arrays too.
s
@Artem Kobzar since you seem to have had a looksy, would you suggest creating a ticket for this as a bug?