P2767 R2 flat_map/flat_set omnibus

[wg21bot]

P2767R0 flat_map/flat_set omnibus (Arthur O'Dwyer)

[JeffGarland]

@brycelelbach this needs LEWG attention. From the paper:

Some of the proposed solutions are LEWG-level design changes. Contrariwise, some of the issues collected here don’t have "solutions" at all, but are recorded merely For Your Information (for other vendors/implementors) to document the design choices libc++ has made.

Quick reading is that ‘at least these’ sections
4. Accidentally explicit constructor
5. Add move semantics to flat_set::insert_range
6. Add move semantics to flat_map::insert_range
7. insert is more primitive than emplace

[wg21bot]

P2767R1 flat_map/flat_set omnibus (Arthur O'Dwyer)

[wg21bot]

P2767R2 flat_map/flat_set omnibus (Arthur O'Dwyer)

[inbal2l]

2023-10-17 Library Evolution Telecon

P2767R1: flat_map/flat_set omnibus

2023-10-17 Library Evolution Telecon Minutes

Champion: Arthur O'Dwyer
Chair: Fabio Fracassi
Minute Taker: Ben Craig

Summary

The room was not convinced that all the changes were required, and was asking for:

• Mark in the paper "Breaking" and "non-breaking" changes (possibly split into different papers).
• Mark in the paper LEWG and LWG targeting changes.
• Review the minutes and apply motivation on the topics that came up during the telecon.
• Benchmarks that show the difference in approaches (fixed scan size vs. unfixed scan vs. 2 lg n)
• Paper to consider code complexity in proposed approaches, both theoretically and in practice (some implementations use emplace_back with rotation, etc.)
• Get feedback from the original author of flat_map (P0429), flat_set (P1222) on the proposed changes.

No polls were taken.

Next Steps

The author should publish a revision that includes the requested changes under "Summary", among which - adding motivation to each change in the paper, split into "Breaking" and "Non-Breaking" changes as well as LEWG and LWG targeting changes.
The room also asked for benchmarks for the proposed algorithmic changes.

[ldionne]

@inbal2l Hi! We are currently implementing flat_map for libc++ (llvm/llvm-project#98643) and we are revisiting many issues brought up in this paper. I think it would be useful to ensure that this paper makes progress, as some of the topics in the paper have fairly obvious resolutions. Do you think it would be better to tackle some of those as LWG issues instead?

[cor3ntin]

#2211 contains a subset of the changes proposed in P2767 and should be seen first