David Widmann

> This has merge conflicts Only after #85 was merged. When the PR was opened it had no conflicts.

That's besides the point - of course, if something is not supported by e.g. `NaNMath.sqrt` then calling it it with such an argument will error. If `Complex` numbers are safe,...

I want to use NaNMath in my MTK-based ODE models to ensure that function evaluation never crashes but only returns NaN if there's a numerical issue. This safety aspect is...

I'll vote against a change for the reasons I outlined above. If a different behaviour is desired in SymbolicRegressions, then probably NaNMath is not the right tool for its use...

ForwardDiff, DiffRules, ReverseDiff, and Tracker have all supported NaNMath for many years, and also defined derivatives for NaNMath functions. So I don't think AD is necessarily a problem with NaNMath....

Please let's just merge this PR and move this discussion to an issue. Breaking the core API guarantees and putting this change in a non-breaking release is basically the worst...

> In particular, i would like opt-in support Well, then it seems you'd want the API without generic fallback 😄 I should also emphasize that even without generic fallback by...

It broke the API guarantees for any special number type that had not opt in to the NaNMath API. For instance, ```julia julia> using NaNMath, Unitful julia> NaNMath.sqrt(u"-1s^2") ERROR: DomainError...

That's similar to how I would imagine it. > Maybe the thing that NaNMath actually needs is just an interface I don't think that's needed. I would use ```julia NaNMath.sqrt(x::Complex)...

Related: #77, #158