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.
Section: 25.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, 25.7.12.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.
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: