Re: [charconv] is std::from_chars practical?

From: Julien Blanc (julien.blanc_at_[hidden])
Date: 2024-01-26 08:55:22

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