@inbal2l @cor3ntin don't do a motion to send this to electronic polling immediately; just do an initial review on the mailing list to get feedback. If the feedback is all positive and no revisions are required, email me so we can discuss next steps.

The author is unavailable for this paper to be reviewed at the 2022-11 Kona meeting.

2023-02-10 08:30 to 10:15 Issaquah Library Evolution Meeting

P2580R0: Tuple protocol for C-style arrays T[N]

2023-02-10 08:30 to 10:15 UTC-8 Issaquah Library Evolution Minutes

Champion: Paolo Di Giglio (R)

Chair: Ben Craig (IP) & Inbal Levi (IP)

Minute Taker: Steve Downey (IP)

Start: 2023-02-10 09:17 UTC-8

Can this proposal be subsumed by P2141?

POLL: We should promise more committee time to pursuing "Tuple protocol for C-style arrays T[N]", knowing that our time is scarce and this will leave less time for other work.

Attendance: 24 local, 16 remote

# of Authors: 1

Author Position: SF

Outcome: No consensus to spend further time.

End: 09:42

Summary

Concerns about the paper:

• The benefit of this paper seems low. There weren't endorsements along the lines of "I have one of these in my code base", but there were statements along the lines of "I've never needed this".
• This paper could be subsumed by P2141. Counterpoint though, P2141 may not be implementable as is.
• This might change the meaning of code with usages of tuple_cat on string literals.
• Null termination of string literals can lead to surprising tuple_cat behavior
• This might change the behavior of tuple_flatten

If the issues with code changing meaning can be resolved (or demonstrated to not be a change in meaning), and P2141 stalls, then the committee may still want to look at this, though likely as a low priority addition.

Next Steps

We currently aren't interested, but if you have substantial additional motivation, then we can consider it. Get scary examples from Zach Laine, and scary flatten tuple cases.