Hello David, This is interesting! The JavaScript behavior is definitively not a good one, that said the only thing that I think could do more harm than good is the fact these checks are enabled by default. I am not sure the majority of cljs user will want to take a performance hit (or have to set a flag to disable it) on this given the fields where it will most likely be used (web ui, web backends), and it might not be obvious to the newcomer. I would rather have it disabled by default and have to (set-checked- arithmetic! true) to enable it. But I could be wrong, and in the end it is mostly a strategy decision, being convenient vs doing it right (fixing JS). Max
On Jan 27, 10:03 pm, David Nolen <dnolen.li...@gmail.com> wrote: > In this > branchhttps://github.com/clojure/clojurescript/compare/master...checked-ari..., > I've implemented one possible approach to checked arithmetic for > ClojureScript. In Clojure this means checking for overflow. In JavaScript a > much more common source of error is type coercion from the arithmetic > operators as well as the introduction of Infinity and NaN. > > These changes would prevent the production of NaN and Infinity at least > from within ClojureScript itself. Also operations like: > > (+ 1 2 "3") > > fail instead of producing > > "33" > > Of course such changes would impose a performance hit. You can currently > toggle the behavior with the following macro: > > (set-unchecked-arithmetic! true) > > This is useful when writing performance sensitive code. > > Feedback, improvements appreciated. > > David -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
