On Wed, Oct 8, 2025 at 4:10 PM Peter Dimov via Boost <boost@lists.boost.org> wrote:
There are at least two reasons to not do that. First, NaN is a possible legitimate return value, so you have no way to reliably determine failure.
Second, it makes it very easy to forget to check for errors.
This is not the same as 0.0 / 0.0 returning NaN. We do that for the practical reason that we don't want, after several hours of computation, element 17108 out of 1048576 in total causing the loss of all the results because of a floating point exception terminating the process.
This constructor / factory function is used to convert _input_ values, at the outer perimeter, and should therefore validate them.
I fully agree, libraries should avoid atoi kind of problems <https://stackoverflow.com/questions/1640720/how-do-i-tell-if-the-c-function-atoi-failed-or-if-it-was-a-string-of-zeros>, , But also users are often averse to error checking for verbosity reasons. Maybe(I am not sure) nice API would be to return NaN in case of parse failure(for people "certain" input is fine), but also provide overload that takes error code as out argument? I personally prefer optional API, but those are not that common in C++, library is C++14, may be slower.... so I will not suggest that. :)