There is an open issue with LWG here:https://cplusplus.github.io/LWG/lwg-active.html#3081. The standard for <charconv> does not distinguish between underflow and overflow like strtod does. Let's say you are writing a JSON library and you replace strtod with charconv for performance reasons. Charconv returns std::errc::result_out_of_range on some conversion. Now what? You would have to parse the string again yourself to figure out which of the four possible reasons you got std::errc::result_out_of_range. Charconv already had this information but could not give it to you. By implementing the resolution to the LWG issue that matches the established strtod behavior I think we are providing the correct behavior without waiting on the committee. Andrzej did bring this up as well, and a macro BOOST_CHARCONV_STD_ERANGE was added to match what the standard says today.
After reading this and the related issue (https://github.com/cppalliance/charconv/issues/110) I actually strongly oppose the existing macro BOOST_CHARCONV_STD_ERANGE. It doesn't change the behavior of the users application but that of the compiled (Boost) library. And if given a compiled library there is a) no way to know the actual behavior of `from_chars` and b) there could be(?) ODR violations when using the library statically. As it seems to be only about whether the pass-by-reference value is modified it seems to be trivial to implement a wrapper around `boost::charconv::from_chars`, that is basically https://github.com/cppalliance/charconv/pull/111/files#diff-de4e106c65731933... I would even go as far as prodiving that function in Boost::CharConv, e.g. as `from_chars_strict` which could probably even be a template. To reiterate: Having the BOOST_CHARCONV_STD_ERANGE macro (and similar ones) makes the behavior of from_chars unpredictable which to me would be a reason to reject the library. To me it would be better to have "wrong" behavior than unknown behavior. Alex