On Wed, 30 Apr 2025, 05:16 Jan Schultke via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> > Which begs the question: if you need this type of configurability, why
> don't
> > you just use libdouble-conversion?
>
> It would be pretty ridiculous if you pulled in a third-party
> dependency just because you have a comma as a radix point instead of
> a dot.
>
> Also, keep in mind that this is about extending the standard library.
> The standard library should provide the low-level, hard-to-implement
> parts so that libraries such as double-conversion can be built on top
> of it.
>
> The class you've referenced provides a large amount of fluff that the
> user can easily do themselves. It's trivial to detect if the string is
> "NaN" or "inf" and treat that as a NaN or infinity float. It's trivial
> to add flags in our parser for case sensitivity, it's trivial to
> remove a leading "0x", etc. There are a million flags and options you
> could add here.
>
> What's not trivial is turning digit sequences into a floating-point
> number. That is the low-level part of the problem that needs to be
> supported by the standard library.
>


If you have already found the boundaries of the integer part and fractional
part, represented as sequence of digits, isn't converting those digits to
integers also easy for the user to do efficiently? Does that part belong in
the lowest level interface?

If your interface takes integers for all three arguments, then the user is
doing the parsing steps that might need to handle digit separators.

Taking strings also presents a problem for hex floats. What base is the
string in?

parse_float("1", "23");

Is this 1.23e0 or 0x1.23p0?

If the user has to convert "1" and "23" to integers then they can do so for
the right base.