P2047 R7 An allocator-aware optional type

[wg21bot]

P2047R0 An allocator-aware optional type (Nina Ranns, Pablo Halpern, Ville Voutilainen)

[cor3ntin]

Author informed me a new revision will be available soon, postponing the mailing list review

[wg21bot]

P2047R1 An allocator-aware optional type (Nina Ranns, Pablo Halpern Ville Voutilainen)

[inbal2l]

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.

[wg21bot]

P2047R2 An allocator-aware optional type (Nina Ranns, Pablo Halpern, Ville Voutilainen)

[brycelelbach]

Deferred to C++26 due to lack of time.

[brycelelbach]

It sounds like this needs to go to Library Evolution telecon so we can decide if we want to do something broader.

[billy-baker]

2022-07-19 Library Evolution Telecon

P2047R2: An allocator-aware optional type

2022-07-19 Library Evolution Telecon Minutes

Chair: Billy Baker

Minute Taker:

Champion: Pablo Halpern

Chair Notes

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.

Next Steps

This paper will be revised and return to Library Evolution for further review.

[wg21bot]

P2047R3 An allocator-aware optional type (Nina Ranns, Pablo Halpern Ville Voutilainen)

[wg21bot]

P2047R4 An allocator-aware optional type (Nina Ranns, Pablo Halpern Ville Voutilainen)

[wg21bot]

P2047R5 An allocator-aware optional type (Nina Ranns, Pablo Halpern Ville Voutilainen)

[brycelelbach]

P2047R6 An allocator-aware optional type (Nina Ranns, Pablo Halpern Ville Voutilainen)

[brycelelbach]

2023-02-06 10:30 to 12:00 Issaquah Library Evolution Meeting

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:

• Examples?
  • No.
• Field experience?
  • Implementation experience?
    • Yes, will be linked in the next revision.
  • Usage experience?
    • Yes, internally at some organizations.
  • Deployment experience?
    • Yes, internally at some organizations.
• Performance considerations?
  • More exploration of the compile time costs are needed.
• Discussion of prior art?
  • Yes.
• Changes Library Evolution previously requested?
  • Yes.
• Wording?
  • Yes.
• Breaking changes?
  • No.
• Feature test macro?
  • No, will be added in the next revision.
• Freestanding?
  • No.

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

Summary

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.

Next Steps

We will not pursue P2047R6 (An allocator-preserving optional), unless there is substantial new information.

[wg21bot]

P2047R7 An allocator-aware optional type (Nina Ranns, Pablo Halpern Ville Voutilainen)

[inbal2l]

Will be seen post P3002, as the motivation for it strongly correlated (and to avoid repeating the same arguments).