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

### 3118. `fpos` equality comparison unspecified

Section: 31.5.3.2 [fpos.operations] Status: WP Submitter: Jonathan Wakely Opened: 2018-06-04 Last modified: 2022-11-17

Priority: 4

View all other issues in [fpos.operations].

View all issues with WP status.

Discussion:

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.

[2018-06-23 after reflector discussion]

Priority set to 4

[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 31.2.2 [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 31.5.3.2 [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)` |
>   > …

[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-11-02; LWG telecon]

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

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

Proposed resolution:

This wording is relative to N4917.

- Modify in 31.5.3.2 [fpos.operations] as indicated:

  > 1. (1.1) — […]

  > 2. […]

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

  > Table 124: 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` | `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 `p == q` is `true` only if `o == o2` is `true`.
  > `p != q` | convertible to `bool` | `!(p == q)` |
  > …