The bug comes from this function from the binding code:
//@ts-ignore
@global
function encode<T>(encoder: JSONEncoder, value: T, name: string | null = ""): JSONEncoder {
if (isBoolean<T>()) {
//@ts-ignore
encoder.setBoolean(name, value);
} else if (isInteger<T>()) {
if (value instanceof i64 || value instanceof u64) {
//@ts-ignore
encoder.setString(name, value.toString());
} else {
//@ts-ignore
encoder.setInteger(name, value);
}
//@ts-ignore
} else if (value == <T>null) {
encoder.setNull(name);
} else if (isString<T>()) {
//@ts-ignore
encoder.setString(name, value); // <-------------------------- HERE
} else if (isReference<T>()) {
if (isArrayLike<T>(value)) {
if (value instanceof Uint8Array) {
//@ts-ignore
encoder.setString(name, base64.encode(<Uint8Array> value));
} else {
encoder.pushArray(name);
for (let i: i32 = 0; i < value.length; i++) {
//@ts-ignore
encode(encoder, value[i], null);
}
encoder.popArray();
}
} else { // Is an object
if (value instanceof u128){
encoder.setString(name, value.toString());
} else {
//@ts-ignore
value.encode(encoder, name);
}
}
} else {
throw new Error("Encoding failed");
}
return encoder;
}
It complains that it's possibly null, but as you can see there is a null check right before. Then I add the ! to make the error go away and get the warning that it can't be null...
This seems to be a bigger issue with upstream. I'll keep playing around to see what it the problem is but I can say that I really hate null.
The bug comes from this function from the binding code:
It complains that it's possibly null, but as you can see there is a null check right before. Then I add the ! to make the error go away and get the warning that it can't be null...
This seems to be a bigger issue with upstream. I'll keep playing around to see what it the problem is but I can say that I really hate null.
Can a default string value be "" instead of null?