You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 6, 2019. It is now read-only.
Currently type unions in return types get converted to "dynamic". This is pretty unsafe. I'm proposing a safer method, with some Kotlin code attached.
Given a function that returns string|number, generate:
externalfunsomeFunction() : StringOrNumber;
externalclassStringOrNumberinlinefun <T> StringOrNumber.destructure(
onString: (String)->T,
onNumber: (Number)->T
) : T{
if("string".equals(jsTypeOf(this))){
return onString(this.unsafeCast<String>())
} elseif("number".equals(jsTypeOf(this))){
return onNumber(this.unsafeCast<Number>())
} else {
throwIllegalStateException("Value is neither type 'string' nor type 'number': ${this}")
}
}
The inline function would have to be generated in a separate Kotlin file, but it could make for safer code, which might improve the quality of the converter itself. We'd need a type discriminant per type, however. Some libraries define their own type discriminants, but following a basic primitive type/known disjoint properties method could be helpful, especially with string literal types.
I can try to generate a proof of concept implementation if this seems okay.
The text was updated successfully, but these errors were encountered:
Sorry for the delay!
It looks too verbose to me. One possible solution that we discussed is using an annotation on the type and write some checker in Kotlin JS frontend.
Currently type unions in return types get converted to "dynamic". This is pretty unsafe. I'm proposing a safer method, with some Kotlin code attached.
Given a function that returns string|number, generate:
The inline function would have to be generated in a separate Kotlin file, but it could make for safer code, which might improve the quality of the converter itself. We'd need a type discriminant per type, however. Some libraries define their own type discriminants, but following a basic primitive type/known disjoint properties method could be helpful, especially with string literal types.
I can try to generate a proof of concept implementation if this seems okay.
The text was updated successfully, but these errors were encountered: