US 46-107 25.5.7.1 [counted.iterator] Too many iterator increments

[wg21bot]

r | take(n) currently advances the underlying range’s iterator n times past r.begin(), when it really only needs to advance n-1 times. This can lead to surprising and dysfunctional behavior in some contexts that needs to be addressed.

Proposed change:

Adopt P2406 or an alternative solution in this space.

[brycelelbach]

The proposed resolution is to adopt P2406 cplusplus/papers#1076

[inbal2l]

Scheduled for SG9's meeting in Kona, first session (08:00-9:45): https://wiki.edg.com/bin/view/Wg21kona2022/SG9

[inbal2l]

Reviewed by SG9 at Kona2022 meeting (Full Minutes).

Polls

POLL: We support the need to solve the issue brought up on NB comment “US#523: US 46-107 25.5.7.1 [counted.iterator] Too many iterator increments”.

SF	F	N	A	SA
5	5	0	0	0

Attendance: 18 (10 on-site, 8 online)

# of Authors: 1

Author’s position: SF

Outcome: Unanimous consensus in favor

POLL: We support applying the solution in the paper “P2578R0 Block eager input (non-forward) iterators from counted_iterator” for C++23.

SF	F	N	A	SA
0	1	1	5	4

Attendance: 19 (11 on-site, 8 remote)

# of Authors: 1

Author’s position: F

Outcome: Consensus against

POLL: We support applying the solution in the paper “P2406R0 Fix counted_iterator interaction with input iterators” for C++23.

SF	F	N	A	SA
1	0	0	3	6

Attendance: 19 (11 on-site, 8 remote)

# of Authors: 1

Author’s position: SF

Outcome: Consensus against

Summary

We started the discussion by identifying the problem. There was an agreement of the importance of the issue, but the proposed solution was not accepted.

SG9 agrees with the importance of fixing this issue but does not support the changes currently proposed in the papers (blocking, lazy versions). I would recommend sending the different alternatives in the reflector to start a discussion and get guidance from the group on possible alternative resolutions.

The issue was forwarded to LEWG.

[inbal2l]

The updated paper got additional design feedback from SG9 (2023-01-02 Minutes)

Forwarded to LEWG for C++23 with the recommended design options (Options 2, and I), for C++23 (to be confirmed by an electronic poll / Issaquah 2023 meeting review)