P2276 Fix std::cbegin(), std::ranges::cbegin, and cbegin() for span (fix of wrong fix of lwg3320)

[wg21bot]

P2276R0 Fix std::cbegin(), std::ranges::cbegin, and cbegin() for span (fix of wrong fix of lwg3320) (Nicolai Josuttis)

[JeffGarland]

Removing the LWG tag until LEWG is done.

[brycelelbach]

2021-02-09 Library Evolution Telecon

P2278R0: cbegin should always return a constant iterator

2021-02-09 Library Evolution Telecon Minutes

Chair: Nevin Liber

Champion: Barry Revzin

Minute Taker: Ben Craig

POLL: Do we want P2278R0 including adding .cbegin() and .cend() for span?

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
3	16	3	1	1

Attendance: 28

# of Authors: 1

Author Position: WF

Outcome: Consensus

SA: Don’t want .cbegin and .cend in span
WA: It is likely that the German National Body will still want the changes from P2276

Finland will disagree with those changes: does not want the range additions of .cbegin() and .cend()

POLL: Do we want P2278R0 excluding adding .cbegin() and .cend() for span?

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
12	5	3	0	1

Attendance: 28

# of Authors: 1

Author Position: WF

Outcome: Strong consensus (much stronger than the previous poll).

SA: It is likely that the German National Body will still want the changes from P2276

Summary

Strong consensus to move forward with this paper excluding adding .cbegin() and .cend() to span. The room considered the latter to be an orthogonal issue, which will require more motivation than was presented.

Note: P2276 was scheduled to be presented with this paper; however, due to a miscommunication the author was not present. P2276 will be given a chance to be presented.

Outcome

Strong consensus to move forward with the paper, excluding adding .cbegin() and .cend() to span. The paper will need a revision with wording, and won't move out of LEWG w/o giving P2276 a chance to be presented.

[FabioFracassi]

2021-03-22 Library Evolution Telecon

P2276R0: Fix std::cbegin(), std::ranges::cbegin, and cbegin() for span (fix of wrong fix of LWG3320)

2021-03-22 Library Evolution Telecon Minutes

Poll: std::cbegin, std::ranges::cbegin() and member .cbegin() should return the same iterator type if .cbegin() exists.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
6	7	5	6	0

Attendance: 36

# of Authors: 1

Author Position: SF

Outcome: Weak Consensus.

Poll: Member .cbegin() (if it exists) should be used instead of .begin() to generate a constant iterator

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
10	9	0	4	0

Attendance: 36

# of Authors: 1

Author Position: SF

Outcome: Strong consensus.

Poll: span should have .cbegin() etc as member function

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
8	15	2	0	1

Attendance: 35

# of Authors: 1

Author Position: SF

Outcome: Strong consensus

SA: We should not add member functions to all views, which we should do if span has it.

Summary

We discussed interactions between std::cbegin(), std::ranges::cbegin() and member .cbegin(). On the question of wether all three ways of arriving at a constant iterator should lead to the same result there was some uncertainty wether we can change the status quo towards that goal without breaking valid code.

There was fairly strong consensus that span should support member .cbegin(), and that if a type features member .cbegin() support it should be used to generate a constant iterator.

Outcome

Library Evolutions expressed preferred design between P2276 and P2278 is currently slightly ambiguous. A joint proposal by the two authors would be very welcome. Otherwise a detailed explanation of the backwards compatibility changes will be needed in the next revision of the paper