Proposed resolution:

This wording is relative to N4917.

[ 2022-11-12 Approved at November 2022 meeting in Kona. Status changed: Voting → WP. ]

[ 2022-11-02; LWG telecon ]

Moved to Ready. For: 6, Against: 0, Neutral: 0

[ 2022-11-02; Daniel comments and improves wording ]

LWG discussion of P2167R2 has shown preference to require that the equality operations of fpos should be specified to have type bool instead of being specified as "convertible to bool". This has been reflected in the most recent paper revision P2167R3. The below wording changes follow that direction to reduce the wording mismatch to a minimum.

[ 2022-05-01; Daniel comments and provides wording ]

The proposed wording does intentionally not use a form involving addition or subtraction to prevent the need for extra wording that ensures that this computed value is well-defined. According to [stream.types], streamoff is a signed basic integral type, so we know what equality means for such values.

Previous resolution [SUPERSEDED]:

This wording is relative to N4910.

Modify in [fpos.operations] as indicated:

[Drafting note: The return type specification of operator== should be resolved in sync with D2167R2; see also LWG 2114.]

1. (1.1) — […]

2. […]

3. (1.5) — o and o2 refers to a values of type streamoff or const streamoff.

Table 119: Position type requirements [tab:fpos.operations]

Expression	Return type	Operational semantics	Assertion/note pre-/post-condition
…
P p(o); P p = o;			Effects: Value-initializes the state object. Postconditions: p == P(o) is true.
…
O(p)	streamoff	converts to offset	P(O(p)) == p
p == q	convertible to bool		Remarks: For any two values o and o2, if p is obtained from o converted to P or from a copy of such P value and if q is obtained from o2 converted to P or from a copy of such P value, then bool(p == q) is true only if o == o2 is true.
p != q	convertible to bool	!(p == q)
…

[ 2018-06-23 after reflector discussion ]

Priority set to 4

The fpos requirements do not give any idea what is compared by operator== (even after Daniel's P0759R1 paper). I'd like something to make it clear that return true; is not a valid implementation of operator==(const fpos<T>&, const fpos<T>&). Maybe in the P(o) row state that "p == P(o)" and "p != P(o + 1)", i.e. two fpos objects constructed from the same streamoff values are equal, and two fpos objects constructed from two different streamoff values are not equal.