This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.
fpos and stateTSection: 31.5.3.2 [fpos.operations] Status: Resolved Submitter: Great Britain Opened: 2016-11-09 Last modified: 2020-05-12
Priority: 4
View all other issues in [fpos.operations].
View all issues with Resolved status.
Discussion:
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").
[2020-05-12; Reflector discussions]
Resolved by P0759R1.
Rationale:
Resolved by P0759R1.Proposed resolution: