P2726 Better std::tuple Indexing

[wg21bot]

P2726R0 Better std::tuple Indexing (Zach Laine)

[brycelelbach]

2023-02-09 13:00 to 15:15 Issaquah Library Evolution Meeting

P2726R0: Better tuple Indexing

2023-02-09 13:00 to 15:15 UTC-8 Issaquah Library Evolution Minutes

Champion: Zach Laine (IP)

Chair: Bryce Adelstein Lelbach (IP) & Robert Leahy (IP)

Minute Taker: Steve Downey (IP)

Start: 2023-02-09 14:37 UTC-8

Does this paper have:

• Examples?
  • Yes.
• Field experience?
  • In Boost Hana, but not from specification or in a Standard Library.
• Performance considerations?
  • Not discussed.
• Discussion of prior art?
  • Yes.
• Changes Library Evolution previously requested?
  • Yes.
• Wording?
  • No.
• Breaking changes?
  • No.
• Feature test macro?
  • Will be added with wording.
• Freestanding?
  • Yes.

Integral constant parameter is missing from the wording in option 2.

POLL: Add tuple::operator[] that takes a constexpr_t-like index.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
7	5	3	4	1

Attendance: 18 (in person) + 10 (remote)

# of Authors: 1

Author Position: SF

Outcome: No consensus; leaning in favor.

SA: I don't buy the motivation; I think it makes tuple more complicated.

WA: If we do this, then everything tuplelike will have to have both get and this.

N: I'd want the version of this where you can say t[42] that requires a language feature.

WA: I think a lot of people would be asking me why can't I write t[42].

WA: I'd be more inclined if we had a non-member operator[] and we could didn't have to add this to every tuple-ish thing.

SF: These arguments are changing my mind. I think I'd vote against now.

N: I think I'm missing the big picture here. I feel like I'm missing the big picture here. What do we do for all tuple-like things, including aggregates, etc. I'd have to see hear more of that big picture to understand if I want it or not.

POLL: Add a forwarding overload of get(t, N) that calls get<N::value>(t) if it's well formed to do so.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
1	5	7	1	6

Attendance: 17 (in person) + 11 (remote)

# of Authors: 1

Author Position: N

Outcome: No consensus.

End: 15:14

Summary

We considered this paper, which proposes new facilities to improve indexing tuple and tuple-like things. It adds operator[] to tuple and tuple-like things and/or a new forwarding overloads of get that take an integral constant as a function parameter and call the underlying get with the value of said constant.

We didn't have consensus to add either facility. Many of those opposed felt that they would complicate the interface and that we should instead wait for a language facility that would make t[42] work.

Next Steps

Bring a revision of P2726R0 (Better tuple Indexing) to Library Evolution for further design review.