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