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.


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, [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: