About the parsing functions, what motivated having errors conveyed as thrown exception or nil?

this is covered in the ticket https://clojure.atlassian.net/browse/CLJ-2667

there are two categories of things: 1) string in invalid format - this is an expected possibility and returns nil so you can nil pun and decide what to do in this case 2) unexpected input (nil, not strings, etc) - no defined behavior, may throw

in many contexts you may know that #2 is not a possibility and you can ignore it (often we know a value is coming from a CLI option, or config file, or text field). If it could literally be anything, you can either guard before or catch after, depends on your needs

we are considering some additional nil validator functions that would combine with these and let you throw on the nil case. not sure yet whether we will do that or not

Re: clojure.java.math ns in Clojure 1.11 Alpha 3. I'm a bit surprised that type hints are still needed?

I have (Math/abs ^long days) and thought I could replace that with (clojure.java.math/abs days) but got an error :

Reflection warning, /Developer/workspace/wsmain/clojure/bases/admin/src/ws/admin/handlers/legacy_membership.clj:27:17 - call to static method abs on java.lang.Math can't be resolved (argument types: unknown).

Math/abs is type overloaded. How would the compiler figure out which one to call (unless we had 4 different fns)?

@potetm Yes, I know that Math/abs is overloaded. That's why I have to have ^long in my code today. I hoped that clojure.java.math/abs would let me remove that type hint.

My question is "what benefit does clojure.java.math provide if I still need type hints?"