Open wg21bot opened 4 years ago
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. Paper: https://wg21.link/P2080 Discussion: https://wiki.edg.com/bin/view/Wg21prague/P2080?twiki_redirect_cache=5f21bb7a48b999eacea108a04aacdcd3 Author: If this is a direction LEWG wants to follow, I'm happy to amend the proposal to a more allocator generic optional type. I'd be hesitant to do so until we have an agreement and a decision that this is a direction we want to take.
It seems like we can just as well put the allocator-aware optional into the same header as the existing optional. Author: Agreed.
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)
Deferred to C++26 due to lack of time.
It sounds like this needs to go to Library Evolution telecon so we can decide if we want to do something broader.
P2047R2: An allocator-aware optional type
2022-07-19 Library Evolution Telecon Minutes
Chair: Billy Baker
Minute Taker:
Champion: Pablo Halpern
POLL: Provide basic_optional (unlimited flexibility/fancy pointer) rather than std::pmr::optional (simplified model/ignore allocation traits) for an allocator aware optional.
Strongly Favor | Weakly Favor | Neutral | Weakly Against | Strongly Against |
---|---|---|---|---|
1 | 4 | 2 | 0 | 0 |
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.
This 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)
P2047R6: 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 optional
in the Standard Library.
Strongly Favor | Weakly Favor | Neutral | Weakly Against | Strongly Against |
---|---|---|---|---|
4 | 6 | 7 | 4 | 4 |
Attendance: 23 (in person) + 10 (remote)
# of Authors: 2
Author Position: 2x SF
Outcome: No consensus.
End: 12:04
This paper proposes adding an allocator-preserving optional
. There was debate about the merits of doing this and how widely it would be used. There was concern about modifying optional
itself; some who were opposed to this paper indicated their objection would be less if we avoided modifying optional
and instead added a new facility.
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.
We will not pursue P2047R6 (An allocator-preserving optional
), unless there is substantial new information.
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)