пт, 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.