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