This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Tentatively Resolved status.
Section: 220.127.116.11 [fpos.operations] Status: Tentatively Resolved Submitter: Great Britain Opened: 2016-11-09 Last modified: 2019-03-26
View other active issues in [fpos.operations].
View all other issues in [fpos.operations].
View all issues with Tentatively Resolved status.
Addresses GB 60
The requirements on the stateT type used to instantiate class template fpos are not clear, and the following Table 108 — "Position type requirements" is a bit of a mess. This is old wording, and should be cleaned up with better terminology from the Clause 17 Requirements. For example, stateT might be require CopyConstructible?, CopyAssignable?, and Destructible. Several entries in the final column of the table appear to be post-conditions, but without the post markup to clarify they are not assertions or preconditions. They frequently refer to identifiers that do not apply to all entries in their corresponding Expression column, leaving some expressions without a clearly defined semantic. If stateT is a trivial type, is fpos also a trivial type, or is a default constructor not required/supported?
Proposed change:Clarify the requirements and the table.
[Issues Telecon 16-Dec-2016]
Priority 4; no consensus for any concrete change
[2019-03-17; Daniel comments]
With the acceptance of P0759R1 at the Rapperswil 2018 meeting this issue should be closed as Resolved (Please note that this paper resolves a historic NB comment that was originally written against C++17 but was at that time responded: "invite a paper if anybody wants to change it - no concensus for change").
Rationale:Resolved by P0759R1.