> Do you have evidence that this extra parsing time is a significant
> problem that your solution would resolve?

I haven't collected the data on this yet, but in any case, it's ultimately
not what makes or breaks the idea. You seem to have misunderstood the idea
as being entirely motivated by performance, which it isn't.

The issue with the std::from_chars interface is first and foremost that
it's inconvenient to build higher-level parsing functions on top of
std::from_chars. For example, Fortran has floats in the format "1.23D+3"
and Ada uses the "16#" prefix for hexadecimal numbers. Wolfram Alpha
accepts a "_16" base suffix. It's also possible that we obtain the integer
and exponent separately from two GUI fields. If we wanted to process
numbers in these formats, we would have to concatenate them back into a
buffer and convert them into the format that std::from_chars accepts. This
isn't entirely trivial; we either allocate by using std::string, or have to
pick a buffer size large enough for integer, fraction, and exponent, and
it's not obvious what that buffer size is.

The first thing that std::from_chars does is split the buffer back into
integer, fraction, and exponent. It is utterly idiotic that we have to
concatenate these parts to use std::from_chars, just so that they're
immediately split back up.

And it's still utterly idiotic even if the performance impact is relatively
low.