P2769 R3 get_element customization point object

[wg21bot]

P2769R0 get_element customization point object (Ruslan Arutyunyan, Alexey Kukanov)

[inbal2l]

Scheduled for SG9 meeting in Issaquah (Monday afternoon).

[brycelelbach]

@inbal2l Y'all look at this first and then send it to us.

[inbal2l]

SG9 (Ranges) reviewed the paper on 2023-02-06 (Full Minutes).

The paper needs additional revision, to explore potential alternative designs and implementation impact

Polls

POLL: The solution proposed in the paper “P2769: get_element customization point object” should be renamed to “std::ranges::get”.

SF	F	N	A	SA
1	2	1	2	1

Attendance: 31

# of Authors: 1

Author Position: SF

Outcome: No Consensus

IL: We need more information - the author should explore if the change will be an ABI break (or not, as suggested by an implementer during the discussion), and which exact use cases will be broken.

POLL: The solution proposed in the paper “P2769: get_element customization point object” should be moved out of the “ranges” namespace (std::get_element”).

SF	F	N	A	SA
2	4	0	1	0

Attendance: 20

# of Authors: 1

Author Position: F

Outcome: Consensus in favor

A: I would prefer seeing this solved by a more broad-range solution in std::

Summary

The paper needs additional revision.

• The author will address alternative solutions in the next revision of the paper:
  • Underscore as placeholders: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2169r3.pdf
  • Customizable functions: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2547r1.html#customizable-function-templates
  • Explore using tuple-like, making everything that uses tuple-like find get via ADL.
• The author will add information on both implementation and the possibility of an ABI break
• Implementation and wording are required

(Chair note: after discussing with the authors of P2547, we suspect there's no reason to avoid this additional CPO, it will be one of many which will need to be addressed if P2547 is accepted)

[brycelelbach]

P2769R1 will be available in the 2023-05 mailing.

[dhollman]

@inbal2l would you like me to schedule this for Kona? Does R1 need to be reviewed by SG9, or were the revisions aimed at LEWG?

[inbal2l]

R0 of the paper was seen by SG9 (as it was targeting < ranges >). Changes were applied, and R1 was reviewed and approved by the SG9 chair, who saw no need for this to be seen again by SG9 and forwarded it to LEWG.

[ben-craig]

2024-01-23 Library Evolution Telecon

P2769R1: get_element customization point object

2024-01-23 Library Evolution Telecon Minutes

Champion: Ruslan Arutyunyan

Chair: Ben Craig

Minute Taker: Eddie Nolan

Summary

POLL: P2769R1 (get_element customization point object) needs to allow for user tuple-likes before it can ship

SF	F	N	A	SA
3	3	4	2	0

Attendance: 21

# of Authors: 1

Author's Position: N

Outcome: Weak consensus

Comments: WA: Value in providing simple projection without necessarily going for the general solution. May be easier to understand if the facility had a less general name.

POLL: LEWG should spend more time on P2769R1 (get_element customization point object)

SF	F	N	A	SA
5	4	0	2	0

Attendance: 21

# of Authors: 1

Author's Position: SF

Outcome: Consensus in favor

Comments: WA: Current paper has wrong motivation. Language solution would be better. Customization point problem seems fine, but that's not this paper.

Next Steps

Come back with another revision that allows for user tuple-likes

p2165r2 has some wording for a generalised tuple_like (and that was approved by LEWG)

[inbal2l]

P2769R2: get_element customization point object (Ruslan Arutyunyan, Alexey Kukanov)

[inbal2l]

2024-06-25 Library Evolution St. Louis Meeting

P2769R2: get_element customization point object

2024-06-25 Library Evolution St. Louis Meeting Minutes

Champion: Ruslan Arutyunyan
Chair: Robert/Eddie
Minute Taker: Guy Davidson

Summary

Actions:

1. The concepts need to be updated to reflect value category in the same way as the customisation point.
2. Constrain concept with having tuple size and tuple element
3. Search for pair_like, if they use get change to get_element.
4. Explore the ADL consequences of the five previously supported types having get, to see if get_element is a worthwhile addition.

POLL: Remove the get_key and get_value variables.

Attendance: 16 IP + 4 R
# of Author's: 1
Outcome: Unanimous dissent (Unanimously against).

POLL: Rename get_key and get_value to get_first and get_second, respectively.

Attendance: 16 IP + 4 R
# of Author's: 1
Outcome: Unanimous dissent (Unanimously against).

POLL: get_element should align with the structured binding protocol by attempting to find member functions named get.

SF	F	N	A	SA
5	5	1	2	0

Attendance: 16 IP + 4 R
Author's Position: A
Outcome: Consensus in favor.

F: deducing this gives this value.
A (author): I would prefer to keep it simple and add this in the future if necessary.

Next Steps

Author should apply the modifications requested, the next revision of the paper should be seen again by LEWG.

[wg21bot]

P2769R3 get_element customization point object (Ruslan Arutyunyan, Alexey Kukanov)

[inbal2l]

2024-11-20 Library Evolution Wroclaw Meeting

P2769R0: get_element customization point object

2024-11-20 Library Evolution Wroclaw Meeting Minutes

Champion: Ruslan Arutyunyan
Chair: Inbal Levi / Robert Leahy
Minute Taker: Steve Downey

Summary

POLL: We should add special handling for specializations of standard library class templates (std::tuple et al.) within std::get_element which causes it to call get qualified (i.e. std::get).

Attendance: 15 (IP) + 4 (R)

Outcome: No objection to unanimous consent

Next Steps

Authors got guidance to add special handling for specializations of standard library class templates (std::tuple et al.) within std::get_element which causes it to call get qualified (i.e. std::get). There are few design questions remain, which will be discussed during the next meeting.