P2769 R1 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)