This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

### 2893. Parsing Hexadecimally in P0067R4

Section: 20 [utilities] Status: NAD Submitter: Great Britain Opened: 2017-02-03 Last modified: 2020-09-06

Priority: Not Prioritized

View all other issues in [utilities].

View all issues with NAD status.

Discussion:

Addresses GB 45

If P0067R4 is applied consider how to parse hexadecimally:

> `to_chars(beg, end, 42, 16);` 16 for hex

> `to_chars(beg, end, 4.2, true);` true means hex

> `to_chars(beg, end, 4.2, chars_format::hex);`

> `to_chars(beg, end, 4.2, chars_format::hex, 2);`

That is: We have 3 different formats to specify hex depending on value types and whether to use precision. Which application programmer should remember this?

May be even worse (I am not sure):

> `to_chars(beg, end, 4.2, 16);`

would silently convert 4.2 to 4 and

> `to_chars(beg, end, 4, chars_format::hex);`

would silently convert 4 to 4.000000.

Proposed change: The various options should be harmonized, possibly by use of an extended enum approach, having the values: dec, hex, scientific, fixed, general with dec (new!) as default for integral values and general for floats

[2017-02-23, Jens Maurer comments]

This issue is NAD; the facility was redesigned with these considerations in mind before it went into the working draft.

[ 2017-06-26 Moved to Tentatively NAD after 5 positive votes on c++std-lib. ]

Proposed resolution: