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

On Fri, Jan 26, 2024 at 1:38 AM Matt Borland via Boost wrote:

...

Hi Everyone, This is about https://github.com/cppalliance/charconv/issues/110, again.

[snip]

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.

I want to underline my support for this. To me, the reason this submission will get the most use is that it implements the standard behavior. This makes it useful for people who are using a pre-C++17 build mode, or an implementation that does not yet provide <charconv>. The perf benefits are nice, but few users will be motivated by that alone, based on the numbers I saw. If the std:: version sucks in some way, the Boost one should suck in exactly the same way, IMO, with of course an available non-sucky alternative. Zach

пт, 26 янв. 2024 г. в 17:36, Zach Laine via Boost :

I want to underline my support for this. To me, the reason this submission will get the most use is that it implements the standard behavior. This makes it useful for people who are using a pre-C++17 build mode, or an implementation that does not yet provide <charconv>. The perf benefits are nice, but few users will be motivated by that alone, based on the numbers I saw. If the std:: version sucks in some way, the Boost one should suck in exactly the same way, IMO, with of course an available non-sucky alternative.

I hold a very different position. This library implements fast locale-unaware conversions between strings of characters and numbers. This is often useful. The API is based on the standard header <charconv> which is beneficial, because it flattens the learning curve. There is also a function that has the exact "sucky" behaviour of the current standard from_chars. Why one would use such a "sucky" function? Presumably, the reason is inability to use a standard library implementation that has <charconv>. And so, such user aims at switching to the standard library version at the first opportunity. My first comment is that after you went all the way to add a physical library dependency to your project, you've paid the cost. What would be the benefit of switching to the standard library equivalent that is actually slower? You spend more effort to get slower code. My second comment is that having compatibility between std::from_chars and charconv::from_chars in such a case prioritises non-users over users. That is, people who need such strict compatibility are people who plan to *not use the library*. People who would prefer the most useful behaviour to be the default are people who plan to continue using the library.