P2568 Proposal of std::map::at_ptr

[wg21bot]

P2568R0 Proposal of std::map::at_ptr (Andrew Tomazos)

[ben-craig]

P2568R0: Proposal of std::map::at_ptr

P2568R0: Proposal of std::map::at_ptr

2022-06-14 Library Evolution Telecon Minutes

Chair: Ben Craig

Minute Taker: Inbal Levi

Champion: Andrew Tomazos

Summary

The main motivation discussed was simplifying very common if statements searching for elements in associative containers.
There was some dissatisfaction with using a pointer return type, as then the monadic optional interfaces wouldn't be available.
Many alternative designs were discussed, including the (controversial and non-existent) optional<T&>, optional<reference_wrapper<T&>>, and expected<T&>.
Adding a bool conversion to indicate end of container for associative containers was also brought up.

Some technical review was done on noexcept correctness (array is different than associative containers here).
We also initially requested that heterogenous at_ptr overloads be added for the associative containers.

POLL: LEWG is happy with returning pointers for at_ptr

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
2	6	2	4	0

Attendance: 18

# of Authors: 1

Author Position: SF

Outcome: No consensus

POLL: We should promise more committee time to pursuing P2568 (something like at_ptr, but not exactly at_ptr), knowing that our time is scarce and this will leave less time for other work.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
2	5	3	3	1

Attendance: 17

# of Authors: 1

Author Position: SF

SA: not much motivation in adding to sequence container.

Next Steps

Closing the paper for now. Stronger motivation is needed to warrant further time.