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.

   […]

[ 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.