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