P2505 Monadic Functions for std::expected

wg21bot commented 2 years ago

P2505R0 Monadic Functions for std::expected (Jeff Garland)

brycelelbach commented 2 years ago

A Library Evolution motion was made to advance this paper directly to electronic polling on 2022-01-11. During the discussion, design questions were raised which remained unresolved at the start of the next electronic polling period. The motion failed on 2022-01-17.

brycelelbach commented 2 years ago

Deferred to C++26.

wg21bot commented 2 years ago

P2505R1 Monadic Functions for std::expected (Jeff Garland)

wg21bot commented 2 years ago

P2505R2 Monadic Functions for std::expected (Jeff Garland)

brycelelbach commented 2 years ago

This is being considered for C++23, at the request of some members, who consider it a bug fix.

ben-craig commented 2 years ago

P2505R2: Monadic Functions for std::expected

2022-05-03 Library Evolution Telecon Minutes

Chair: Ben Craig

Minute Taker: Mark Hoemmenn

Champion: Barry Revzin

Summary

Went carefully through the API. Here are some of the notes that I highlighted.

Deducing this would allow us to constrain on invocability.

transform_error else should use the unexpect constructor.

Corner case, transform. If I return unexpect from my invocable, maybe say function can't return unexpect?

Should mandate that none of the functions can return unexpect.

transform_error should move from from error in the void specialization.

Contention around free functions vs. member functions.

Next Steps

Revise the paper and bring it back to LEWG

brycelelbach commented 2 years ago

2022-06-07 Library Evolution Telecon

P2505R3: Monadic Functions for expected

2022-06-07 Library Evolution Telecon Minutes

Chair: Bryce Adelstein Lelbach

Minute Taker: Ben Craig

Champion: Jeff Garland

Start: 2022-06-07 11:21 Eastern

Does this proposal have:

Examples?
- Yes.
Field experience?
- Implementation experience?
  - Yes. Wakely has a libstdc++ implementation, and there's Sy Brand's implementation, but that is not exactly to spec.
- Usage experience?
  - Yes, in Sy Brand's implementation.
- Deployment experience?
  - Yes, in Sy Brand's implementation.
Discussion of prior art?
- Yes.
Changes Library Evolution previously requested?
- Yes.
Wording?
- Yes.
Feature test macro?
- Yes.

Open Questions:

Should we add error_or as well?
- This is an additive change which could be done later after expected ships.
Should we try to unify this monadic interface with the planned interfaces for senders? E.g. then, upon_error.
- This is an additive change which could be done later after expected and optional ships. We would then have two monadic interfaces, but that seems okay; we shouldn't hold up this one while we wait for a future one.

__POLL: Add error_or to expected for C++23.__

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

Attendance: 21

# of Authors: 1

Author Position: N

Outcome: Consensus in favor.

WA: It could be added later and it doesn't seem critical.

__POLL: Modify D2505R3 (Monadic Functions for expected) by adding error_or and send the revised paper to Library for C++23 classified as an improvement (B2), to be confirmed with a Library Evolution electronic poll.__

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
6	8	0	0	0

Attendance: 21

# of Authors: 1

Author Position: SF

Outcome: Unanimous consensus in favor.

End: 11:50

Authors should publish R3 as-is, and produce an R4 with error_or added before the next Library Evolution polling period.

Summary

D2505R3 (Monadic Functions for expected) adds the applicable elements of optional's monadic interface to expected. We found the paper to be straightforward, as these functions were already reviewed and approved by Library Evolution for optional. Beyond what is in D2505R3, we decided we also wanted to add an error_or function, an analog to value_or that retrieves the error in the expected or returns the provided default. With that addition, Library Evolution wants to send the paper to Library for C++23.

Next Steps

Publish D2505R3 (Monadic Functions for expected) as-is.
Produce and publish P2505R4 (Monadic Functions for expected), adding error_or.
Take an electronic poll to confirm sending P2505R4 (Monadic Functions for expected) to Library for C++23, classified as B2: improvement.

wg21bot commented 2 years ago

P2505R3 Monadic Functions for std::expected (Jeff Garland)

wg21bot commented 2 years ago

P2505R4 Monadic Functions for std::expected (Jeff Garland)

brycelelbach commented 2 years ago

2022-07 Library Evolution Electronic Poll Outcomes

Poll 1.4: Send [P2505R4] Monadic Functions For expected to Library Working Group for C++23, classified as an addition ([P0592R4] bucket 3 item).

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
15	11	0	1	0

Outcome: Consensus in favor.

jwakely commented 2 years ago

Scheduled for LWG telecon tomorrow. See the mailing list for details.

jwakely commented 1 year ago

LWG completed the review of P2505R5 and approved it for the working draft, once it's open for new additions again.

jensmaurer commented 1 year ago

Moved to C++26 for now.

wg21bot commented 1 year ago

P2505R5 Monadic Functions for std::expected (Jeff Garland)

brycelelbach commented 1 year ago

2022-11-07 10:00 to 11:30 UTC-10 Kona Library Evolution Meeting

P2505R5: Monadic functions for expected

2022-11-07 10:00 to 11:30 UTC-10 Kona Library Evolution Minutes

Champion: Jeff Garland (in-person)

Chair: Fabio Fracassi & Billy Baker

Minute Taker: Steve Downey

POLL: Adopt P2505R5 for C++23 (LWG already reviewed and approved this version)

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
11	12	1	0	0

Attendance: 28 19 + 9

# of Authors: 1

Author Position: SF

Outcome: Strong consensus in favour

Summary

We consider this to be a consistency fix.

Next Steps

Send to LWG

cplusplus / papers