Re: Boost.Charconv review runs January 15th - 25th, 2024

From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2024-01-17 07:58:04

> 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-de4e106c6573193362b976fb5f98a6ad5fe43f34f0fae6c09098a96c3bed4ac3R61-R71
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