Was seen by SG9 (Ranges) on 2021-08-09

Polls

POLL: Move the paper P2415R0 What is a view? to LEWG

Outcome: No Objection to Unanimous Concent

Summary

Got strong support, forwarded to LEWG

P2415R1 What is a view? (Barry Revzin, Tim Song)

R1 was seen by LEWG on 2021-09-09 and forwarded to electronic polls as a C++20 DR. (Minutes)

Polls

POLL: Forward P2415R1 to electronic polling for C++23 as a B2 item and apply it as a DR for C++20

__Attendance:__22

__# of Authors:__2

__Author Position:__2xSF

__Outcome:__Consensus in favor

Summary

The paper was approved as a C++23 B2 item (in terms of P0592, see Prioritization for more details) , and a C++20 DR.

LWG reviewed and approved with changes as DR for c++20 and for C++23 pending outcome of LEWG polling.

https://wiki.edg.com/bin/view/Wg21telecons2021/P2415-20210924

poll: put p2415r2 into C++23 as a DR for C++20 assuming LEWG like it

2021 September Library Evolution Polls

P2451: 2021 September Library Evolution Poll Outcomes

Poll 2: Send P2415R1 (What Is A view?) to Library Working Group for C++23, classified as an improvement of an existing feature (P0592R4 bucket 2 item), with the recommendation that implementations retroactively apply it to C++20.

Outcome: Consensus in favor.

Selected Comments

The view concept has seen so many changes since its initial proposal that its meaning has become muddled. This paper brings some much-needed clarity and is also a significant usability improvement.

— Strongly Favor

I see the essential feature of a view as "a thing that refers to another thing," rather than its asymptotic complexity. The shared_ptr example of LWG3452 is compelling. Making a thing A refer to another thing B would best happen at A's construction, so it makes sense to me to change the wording to focus on construction, rather than destruction. owning_view sounds a bit funny ("owning" and "view" feel like opposites), but it does neatly solve the problem of dangling rvalue non-view ranges.

— Strongly Favor

The O(1) requirement in views is problematic, this is a step in the right direction

— Weakly Favor

The ranges library is in general overconstrained, requiring that user-supplied types be "well-behaved" in a complete, abstract sense rather than that they actually behave in use. Performance requirements in particular are questionable, since the library cannot act in reliance on them other than via a multiplicative factor.

— Weakly Favor

I am definitely in favor of the change to the complexity requirements. I don't fully understand the other changes or the ramifications of them.

— Neutral

This change would do serious and lasting damage to the design of std::ranges, further muddying the distinction between view and ranges, and opening subtle new opportunities for dangling references. No, no, no.

— Strongly Against

I really believe that rvalue/lvalue difference for meaning of views:all is too subtle, and we will pay for it in year. And I found it unfortunate that this change is bundled, with very useful and welcomed clarification on meaning of view.

— Strongly Against

There are subtleties here that I don't understand and make me uncomfortable participating.

— Did Not Participate

I want to participate in this poll, but I don't think I have the time/knowledge/experience with ranges to do so.

I think it probably makes sense, but I'm not sure of all the ramifications. I would probably go with whatever Eric and Casey say. If the people with experience (ie the paper authors and the ranges authors) all agree with it than great (but I haven't followed enough to even know their opinions).

— Did Not Participate

P2415R2 What is a view? (Barry Revzin, Tim Song)

Adopted 2021-10.