Sure, but 1.01 is the same as 101e-2. For all intents and purposes,
you can treat the digit sequences of integer and fraction as one big
integer, and merely adjust the exponent based on where the radix point
is located.

I'm also not suggesting parse_float(10, 1, -1) at the lowest API
level. The initial step in fast_float is to compute a single uint64_t
for the mantissa, and this is something the user can do if they just
want this part of the library, so they would be passing something
like:

> parse_float(uint64_t(101) << (63-7), 1).

Although this still requires filling up the lower bits of the
mantissa, since .101 cannot be represented in a binary float. I'd have
to dig a bit more into how fast_float does it, but what I do know is
that after the first stage of the problem, it just has a uint64_t
mantissa.

It's not even float parsing at that point anymore; it's really just an
exponentiation with 10 to the power of the exponent, and that is the
really hard part which makes up the vast majority of fast_float code.

And as I've said, you would build multiple levels of wrappers around
that, so the user wouldn't need to touch it usually and could pass
string_view digit sequences instead. Taking two integers as parameters
would be a weird half measure that makes no sense. There is no level
of abstraction between having the uint64_t mantissa and having two
char sequences which makes sense.