New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
P2047 R7 An allocator-aware optional type #777
Comments
Author informed me a new revision will be available soon, postponing the mailing list review |
P2047R1 An allocator-aware optional type (Nina Ranns, Pablo Halpern Ville Voutilainen) |
Was seen on LEWG ML review, attaching a short summary: A request to generalize: The C++ standard library should provide building blocks that allow multiple semantics to be expressed, as opposed to deciding on a narrow subset, and making an allocator-aware optional obey the static properties, namely the propagation traits, of an allocator is a fundamental piece of such genericity. It seems like we can just as well put the allocator-aware optional into the same header as the existing optional. I would suggest scheduling a discussion to get broader feedback on the preferred direction of this paper. Action Item: Waiting for a new revision. |
P2047R2 An allocator-aware optional type (Nina Ranns, Pablo Halpern, Ville Voutilainen) |
2022-07-19 Library Evolution TeleconP2047R2: An allocator-aware optional type 2022-07-19 Library Evolution Telecon Minutes Chair: Billy Baker Minute Taker: Champion: Pablo Halpern Chair NotesPOLL: Provide basic_optional (unlimited flexibility/fancy pointer) rather than std::pmr::optional (simplified model/ignore allocation traits) for an allocator aware optional.
Attendance: 13 # of Authors: 3 Author Position: 1 SF , 2 WF Outcome: Consensus for basic_optional. The poll text in ()'s comes from the presentation. Next StepsThis paper will be revised and return to Library Evolution for further review. |
P2047R3 An allocator-aware optional type (Nina Ranns, Pablo Halpern Ville Voutilainen) |
P2047R4 An allocator-aware optional type (Nina Ranns, Pablo Halpern Ville Voutilainen) |
P2047R5 An allocator-aware optional type (Nina Ranns, Pablo Halpern Ville Voutilainen) |
P2047R6 An allocator-aware optional type (Nina Ranns, Pablo Halpern Ville Voutilainen) |
2023-02-06 10:30 to 12:00 Issaquah Library Evolution MeetingP2047R6: Allocator-aware optional type 2023-02-06 10:30 to 12:00 UTC-8 Issaquah Library Evolution Minutes Champion: Pablo Halpern (IP) Chair: Bryce Adelstein Lelbach (IP) & Ben Craig (IP) Minute Taker: Steve Downey (IP) Start: 2023-02-06 HH:MM UTC-8 Does this paper have:
POLL: We should have an allocator-preserving
Attendance: 23 (in person) + 10 (remote) # of Authors: 2 Author Position: 2x SF Outcome: No consensus. End: 12:04 SummaryThis paper proposes adding an allocator-preserving During our discussion, it became apparent that we need to have a policy discussion about allocator support in the Standard Library. At the end of our discussion, we did not have consensus to pursue the feature in this paper. Next StepsWe will not pursue P2047R6 (An allocator-preserving |
P2047R7 An allocator-aware optional type (Nina Ranns, Pablo Halpern Ville Voutilainen) |
Will be seen post P3002, as the motivation for it strongly correlated (and to avoid repeating the same arguments). |
P2047R0 An allocator-aware optional type (Nina Ranns, Pablo Halpern, Ville Voutilainen)
The text was updated successfully, but these errors were encountered: