If multiplication with the power of ten is the hard part, why not just standardize a function doing that?   Providing character sequences into parts of the float is a really strange interface for standardization. And perhaps better left to the user with separators and decimal point symbol selection. If one provides character sequences than best for parsing the whole float.   -----Ursprüngliche Nachricht----- Von:Jan Schultke via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Do 01.05.2025 11:54 Betreff:Re: [std-proposals] Low-level float parsing functions An:Jonathan Wakely <cxx_at_[hidden]>; CC:Jan Schultke <janschultke_at_[hidden]>; std-proposals_at_[hidden]; 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. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals