Title
§[formatter.requirements]: Formatter requirements forbid use of fc.arg()
Status
new
Section
[formatter.requirements]
Submitter
Alberto Barbati

Created on 2020-06-30.00:00:00 last changed 3 months ago

Messages

Date: 2020-07-12.16:33:28

Proposed resolution:

This wording is relative to N4861.

  1. Modify [concept.convertible], Table [tab:formatter], as indicated:

    Table 67: Formatter requirements [tab:formatter]
    Expression Return type Requirement
    f.format(t, fc) FC::iterator Formats t according to the specifiers stored in *this, writes the output to fc.out() and returns an iterator past the end of the output range. The output shall only depend on t, fc.locale(), and the range [pc.begin(), pc.end()) from the last call to f.parse(pc), and fc.arg(n), where n is a size_t index value that has been validated with a call to pc.check_arg_id(n) in the last call to f.parse(pc).
Date: 2020-07-15.00:00:00

[ 2020-07-12; Reflector prioritization ]

Set priority to 3 after reflector discussions.

Date: 2020-06-30.00:00:00

The requirements on the expression f.format(t, fc) in [tab:formatter] say

Formats t according to the specifiers stored in *this, writes the output to fc.out() and returns an iterator past the end of the output range. The output shall only depend on t, fc.locale(), and the range [pc.begin(), pc.end()) from the last call to f.parse(pc).

Strictly speaking, this wording effectively forbids f.format(t, fc) from calling fc.arg(n), whose motivation is precisely to allow a formatter to rely on arguments different from t. According to this interpretation, there's no conforming way to implement the "{ arg-id }" form of the width and precision fields of standard format specifiers. Moreover, the formatter described in the example if paragraph [format.context]/8 would also be non-conforming.

History
Date User Action Args
2020-07-12 16:33:28adminsetmessages: + msg11363
2020-07-05 17:03:02adminsetmessages: + msg11361
2020-06-30 00:00:00admincreate