woonki
woonki
It seems inevitable as per lambda output. Both `as y` and `Ok(v)` are making the new assignment to the variable which means that the compiler doesn't know y and v...
> Looking great! But I don't think the arithmetic operators can overlap with the regular int ones...? cc @cristianoc Yes, we can define new operator for the bigint, we can...
> Can't we just open the BigInt module for this? If I understand correctly, @tsnobip meant that `Belt.Result.t` before it is moved to the predef.
Similar to @cometkim suggestion, I'm wondering why the comparison operator only checks if the two arguments are the same type, and the arithmetic operator should be split between integer and...
@CarlOlson Yes, indeed. The typechecking logics are quite complex than I expect 😄 Actually, I changed the arithmetic operations to polymorphic for int and bigint for test. I haven't benchmarked...
I'm thinking it's a choice between adding another operator for bigint and changing the operators to a polymorphic type, what do you guys think?
> You could actually even keep it for strings, so it's like JS. I think the JS output maybe look okay, but looks weird in syntax layer. we have string...
We do need the bigint for AOC 2024! (just kidding 😄)
IMHO, there are a lot of advantages to having it as a primitive type, and if we're stuck with the discussion of opening up the Bigint module instead of having...
If we decide to go with primitive types, I think the debate is split between adding new operators and making the arithmetic operators polymorphic. Adding new operators is simpler than...