Le 2024-01-26 08:37, Matt Borland via Boost a écrit :
Hi Everyone, This is about https://github.com/cppalliance/charconv/issues/110, again. Now I understand Peter's point better. std::from_chars is impractical, or one would say "broken", at least for the case of ERANGE. Actually applying a patch in https://cplusplus.github.io/LWG/lwg-active.html#3081 will not make the tool good, it will just make it broken in another way.
In that case, maybe the goal of providing literally a drop-in replacement for std::from_chars is not a good one? Maybe this is the case similar to variant2, where the community would benefit more from the library motivated by "how would from_chars look like if we designed it instead of WG21".
That is, an alternative to std::from_chars, rather than a drop-in-replacement for std::from_chars.
Between here and the Slack channel there seems to be a general consensus that 2 overloads should be provided by Boost.charconv to offer the drop-in replacement, and one with a better designed handling of ERANGE. There is slightly more people saying that boost::charconv::from_chars should match std::from_chars exactly, and then also have a boost::charconv::from_chars_erange with the aforementioned better handling. It seems as the boost components with the exact same naming as STL components with different handling causes some heartburn among the users.
If the road is going to another interface, then is keeping from_chars_result a requirement? The way i see it, the correct fix would indeed be to extend the return value of from_chars to distinguish between the 4 error cases, keeping the guarantee about the value argument. This is not possible using std::errc, but would be if the function used another type instead. Something like: struct from_chars_result_ex { const char* ptr; conversion_result res; }; conversion_result being defined as an enum class { no_error, invalid_argument, out_of_range_too_small_positive, out_of_range_too_big_positive, etc.). For compatibility, there is the possibility to add comparison operators between std::errc and conversion_result. Not sure if that's a good idea, though. Most values in std::errc do not make any sense for from_chars, and yet there is not a way to be precise enough in error reporting. To me it looks like it is not the best suited return type for the function. Regards, Julien