Unimplementable narrowing and evaluation order requirements for range adaptors
Tim Song

Created on 2021-02-19.00:00:00 last changed 1 month ago


Date: 2021-03-15.00:00:00

[ 2021-03-12; Reflector poll ]

Set priority to 3 following reflector poll.

Date: 2021-02-19.00:00:00

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.

Date User Action Args
2021-03-12 15:07:58adminsetmessages: + msg11728
2021-02-19 00:00:00admincreate