Proposed resolution:

This wording is relative to N4727.

1. Edit [charconv.from.chars] as indicated:

   from_chars_result from_chars(const char* first, const char* last, float& value,
                                chars_format fmt = chars_format::general);
   from_chars_result from_chars(const char* first, const char* last, double& value,
                                chars_format fmt = chars_format::general);
   from_chars_result from_chars(const char* first, const char* last, long double& value,
                                chars_format fmt = chars_format::general);
   

   -6- Requires: fmt has the value of one of the enumerators of chars_format.

   -7- Effects: The pattern is the expected form of the subject sequence in the "C" locale, as described for strtod, except that

   1. (7.1) […]

   2. (7.2) […]

   3. (7.3) […]

   4. (7.4) […]

   In any case, the resulting value is one of at most twothe floating-point values closest to the value of the string matching the pattern, with ties broken according to round_to_nearest.

   […]

[ 2024-12-04; add comments from Richard Smith ]

In editorial issue #6730 Richard said:

[charconv.from.chars]/6.4 says:

In any case, the resulting value is one of at most two floating-point values closest to the value of the string matching the pattern.

This is ambiguous. It could mean either:

1. The resulting value is the implementation's choice of one of a set of values, and that set contains the two values closest to the value of the string.
2. The resulting value is the implementation's choice of one of a set of values, and that set contains all values that are closest to the value of the string (of which it turns out there can be up to two).

I think the normal English interpretation would be (1), but the intended interpretation is actually (2).

(Under (1), the string `"1.0"` can produce the value one ULP less than 1.0 or it can produce 1.0, and the string "1.00<lots of 0s>1" can produce those same two values, because the value one ULP less than 1.0 is closer to that string than the value one ULP greater than 1.0.)

Perhaps the wording from [conv.double]/2 and [expr.static.cast]/11 can be used instead:

If the source value can be exactly represented in the destination type, the result of the conversion is that exact representation. If the source value is between two adjacent destination values, the result of the conversion is an implementation-defined choice of either of those values.

Editorial pull request #6833 proposed a change along those lines, but conflicts with the proposed resolution to this issue. We should address Richard's comment as part of this issue.

[ 2018-08-23 Batavia Issues processing ]

Marshall to talk to Jens about this

[ 2018-06 Rapperswil Wednesday issues processing ]

Status to open; also this needs to say that the intent is to be independent of the floating point environment.

[ 2018-03-27 Priority set to 2 after discussion on the reflector. ]

P0682R1 added the requirement that from_chars use round_to_nearest when converting from string, but later text in the section suggests that the implementation has latitude in its choice of rounding logic.

If the intent is merely that the floating point environment should not affect from_chars behavior, the rounding-mode text should be weakened. If the intent is to always require round_to_nearest, the text suggesting a latitude in rounding logic should be removed.