This message contains interactive elements.
I've also gotten a related question for squint and cherry if 123N should be parsed as a BigInt
but I said: well, this will likely result into incompatibilities
So we're happy with edn data not being able to be round tripped because of type mismatches?
When I got the question it wasn't about EDN, but about code. You can get backward incompatibilities when people rely on (+ 10 10N) to work in both Clojure and CLJS
when you change 10N to BigInt, (+ 10 10N) no longer will work
Ah, so it's a larger issue with CLJS just not having a proper numeric tower?
I've never relied on this notation myself, so perhaps it's not an issue, but this something that could potentially break people's code as CLJS has converted 10N to a normal number
I'm curious how big that impact would actually be if CLJS' numeric functions were updated to deal with a proper numeric stack that included arbitrary precision integers and decimals.
the numeric "functions" often just translate into raw "+" JavaScript calls
only in cases where + is used as a higher order function, is that avoided
Right, but part of me thinks that's bad default behavior and should only be turned on for specific parts of code that opt into it. But maybe I'm alone there.
it's a huge performance loss if you would go through a function for those cases, but some of that can be avoided using the inference, just like for truthiness (which does go through a function, since that behavior in CLJS differs from JS)