I would not advise being minimalist here.
As solutions that don't quite go all the way tend to invite new proposals that need more and making "partial implementations" obsolete.
You also can't just provide a solution to convert from A to B without also providing a solution to go from B to A.

I would be more than happy to help you put out a proposal, but it needs to be thorough.
I don't see a value in adding just a little bit when I know from experience that it is not enough and more will be needed that fully replaces it.


________________________________
From: Jan Schultke <janschultke_at_[hidden]>
Sent: Tuesday, April 29, 2025 6:23:16 AM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Tiago Freire <tmiguelf_at_[hidden]>
Subject: Re: [std-proposals] Low-level float parsing functions

I feel like if we really wanted to provide a minimalistic interface in the standard, we could narrow it down to

parse_float(string_view integer, string_view fraction, int exponent = 0);
parse_float_hex(string_view integer, string_view fraction, int exponent = 0);

The exponent can have leading sign symbols, and it's up to the user if those are optional or not. The exponent is also a small integer, and the user could have pre-parsed this. It's basically the least challenging part of parsing floating-point numbers, but the one with the most variations.

That would leave just the integer and fraction part, both of which are pure digit sequences with no additional characters like radix points or digit separators. Passing the leading sign character as bool is unnecessary because for floating-point numbers, it can be parsed separately and attached to the result afterwards, with no loss of precision.

Anything beyond this is optional then, such as supporting simultaneous parsing of the exponent, passing in the sign bit, etc.