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.

### 3524. Unimplementable narrowing and evaluation order requirements for range adaptors

Section: 24.7 [range.adaptors] Status: Resolved Submitter: Tim Song Opened: 2021-02-19 Last modified: 2021-06-14

Priority: 3

View all issues with Resolved status.

Discussion:

The specification of various range factory and adaptor objects generally says that some function call expression on them is expression-equivalent to an expression that performs list-initialization or in some cases a comma expression. This imposes evaluation order requirements that are unlikely to be intended and sometimes outright contradictory. For example, 24.7.10.1 [range.drop.overview] says that `views::drop(E, F)` is expression-equivalent to "`((void) F, decay-copy(E))`" in one case, and `drop_view{E, F}` in another. The first expression requires `F` to be sequenced before `E`, while the second expression requires `E` to be sequenced before `F`. They can't both hold in the absence of high levels of compiler magic.

Additionally, because the core language narrowing check in list-initialization considers the value of constant expressions, "expression-equivalent" also requires the constantness to be propagated. For example, given a range `E` whose `difference_type` is `int32_t`, `views::drop(E, int64_t())` is required to work, but `int64_t l = 0; views::drop(E, l)` is required to be ill-formed. This seems unlikely to be the intent either.

[2021-03-12; Reflector poll]

Set priority to 3 following reflector poll.

[2021-06-13 Resolved by the adoption of P2367R0 at the June 2021 plenary. Status changed: New → Resolved.]

Proposed resolution: