P2527 R3 std::variant_alternative_index and std::tuple_element_index

cplusplus / papers

ISO/IEC JTC1 SC22 WG21 paper scheduling and management

643 stars 18 forks source link

P2527 R3 std::variant_alternative_index and std::tuple_element_index #1181

Open wg21bot opened 2 years ago

wg21bot commented 2 years ago

P2527R0 std::variant_alternative_index and std::variant_alternative_index_v (Alex Christensen)

brycelelbach commented 2 years ago

The current revision does not appear to have wording.

achristensen07 commented 2 years ago

Planning to add wording to R1 if this gets positive feedback.

achristensen07 commented 2 years ago

Also r0 incorrectly says it was published in 2021. It was published in 2022

brycelelbach commented 2 years ago

@achristensen07 I'd add wording now if you can. We can probably fast track it if there's wording and implementation experience.

@inbal2l and @cor3ntin: If we don't have a revision with wording, the initial mailing list review should just be for feedback and sentiment - no motion to forward directly to Library Evolution.

cor3ntin commented 2 years ago

Mailing list review 27-June - 13 July 2022

6 participants

A quick summary: This feature seems useful as multiple people have expressed interest for it, however there is consensus that the author should,at least, explore more generic solutions, namely

This facility should arguably work with tuple
This facility looks like a mp_find in disguise, maybe we should explore that, up to and including restarting the conversation about the mp proposal
EWG is working on better language support for pack, could and should we leverage that - and maybe P1858 (Generalized pack declaration) could show how it would help with this proposal
Additionally, the paper should discuss whether the intended facility is intended to support inherited from variant types, as (some, but not all) variant handling functions do currently support that.

We want to see this paper on the mailing list again, with these questions discussed in the paper.

wg21bot commented 2 years ago

P2527R1 std::variant_alternative_index and std::tuple_element_index (Alex Christensen)

FabioFracassi commented 1 year ago

2022-11-09 13:00 to 15:00 UTC-10 Kona Library Evolution Meeting

2022-11-09 13:00 to 15:00 UTC-10 Kona Library Evolution Minutes

Champion: n/a (Fabio Fracassi presenting)

Chair: Fabio Fracassi

Summary

Short discussion

Next Steps

Paper author produces a revision with the help of a library wordsmith. The revised paper can then go to LWG.

brycelelbach commented 1 year ago

2022-11 Library Evolution Electronic Poll Outcomes

__Poll 2.5: Send [P2527R1] variant_alternative_index And variant_alternative_index_v to Library Working Group for C++26, classified as an improvement of an existing feature ([P0592R4] bucket 2 item).__

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

Outcome: Consensus in favor.

wg21bot commented 1 year ago

P2527R2 std::variant_alternative_index and std::tuple_element_index (Alex Christensen)

wg21bot commented 9 months ago

P2527R3 std::variant_alternative_index and std::tuple_element_index (Alex Christensen)

JeffGarland commented 6 months ago

LWG ended up skipping this paper in Tokyo -- will see it in St. Louis.

JeffGarland commented 3 months ago

Author indicates that there design issues that need to go back to LEWG after questions from LWG in Kona. Adding the LEWG tags.

jwakely commented 3 months ago

LWG comments from Kona (the R3 revision also includes this info):

Poll: do we want LEWG consider SFINAE-friendliness of tuple_element_index rather than a hard error? F	A	N
6	1	4

Author is against

I think it is worth sending that back

Poll: do want LEWG to consider other tuple-like types? F	A	N
3	0	6