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

From: Matt Borland (matt_at_[hidden])
Date: 2024-01-26 10:07:15

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

I'm not sold on changing the return type between the two functions. Using the value argument to convey which direction the over/underflow occurred is established behavior elsewhere in the Standard Library (e.g. strto*). I would agree that there's likely something better than std::errc that could have been chosen, but here we are.

Matt