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

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

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

> Regards,
> &rzej;
> 

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.

Matt