[Bug libstdc++/109947] std::expected monadic operations do not support move-only error types yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109947 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Jonathan Wakely --- Backported as r13-7423-gff58310f274e49 for 13.2
[Bug libstdc++/109947] std::expected monadic operations do not support move-only error types yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109947 --- Comment #9 from Martin Seemann --- That's great news, looking forward to the next point release. Thank you very much for taking this to the committee and getting the process in motion so quickly!
[Bug libstdc++/109947] std::expected monadic operations do not support move-only error types yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109947 Jonathan Wakely changed: What|Removed |Added Status|SUSPENDED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |13.2 --- Comment #8 from Jonathan Wakely --- The LWG issue has been moved to Tentatively Ready status by LWG, and should get approved by the full committee in two weeks. I've implemented the proposed resolution in GCC trunk as r14-1471-gfe94f8b7e022b7 and will backport that to the gcc-13 branch too.
[Bug libstdc++/109947] std::expected monadic operations do not support move-only error types yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109947 Jonathan Wakely changed: What|Removed |Added Status|RESOLVED|SUSPENDED Resolution|INVALID |--- Ever confirmed|0 |1 Last reconfirmed||2023-05-25 --- Comment #7 from Jonathan Wakely --- I've created https://cplusplus.github.io/LWG/issue3938 for this, let's see where that goes.
[Bug libstdc++/109947] std::expected monadic operations do not support move-only error types yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109947 --- Comment #6 from Jonathan Wakely --- (In reply to Martin Seemann from comment #5) > Thanks for the clarification! Now I am convinced that it is not a bug in > libstdc++ (although I still doubt that the side-effects were intended when > the committee formulated the "Effects" for monadic operations, but that's > not relevant here). LWG 3843 was resolved after the monadic ops had been specified, and it's possible that we should have altered the monadic ops to use operator*() instead of value(). I'll raise this with the committee.
[Bug libstdc++/109947] std::expected monadic operations do not support move-only error types yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109947 Martin Seemann changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Martin Seemann --- Thanks for the clarification! Now I am convinced that it is not a bug in libstdc++ (although I still doubt that the side-effects were intended when the committee formulated the "Effects" for monadic operations, but that's not relevant here). Marking as resolved and sorry for the noise.
[Bug libstdc++/109947] std::expected monadic operations do not support move-only error types yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109947 --- Comment #4 from Jonathan Wakely --- (In reply to Martin Seemann from comment #3) > So it comes down to how to interpret the "Effects:" clause: Does "Equivalent > to " mean that all restrictions of > `value()` apply transitively or is it merely an implementation hint? The former. The standard says: Whenever the Effects element specifies that the semantics of some function F are Equivalent to some code sequence, then the various elements are interpreted as follows. If F’s semantics specifies any Constraints or Mandates elements, then those requirements are logically imposed prior to the equivalent-to semantics. Next, the semantics of the code sequence are determined by the Constraints, Mandates, Preconditions, Effects, Synchronization, Postconditions, Returns, Throws, Complexity, Remarks, and Error conditions specified for the function invocations contained in the code sequence. The value returned from F is specified by F’s Returns element, or if F has no Returns element, a non-void return from F is specified by the return statements (8.7.4) in the code sequence. If F’s semantics contains a Throws, Postconditions, or Complexity element, then that supersedes any occurrences of that element in the code sequence. > (Strangely enough, in the "Effects:" clause of `value_or()&&` the expression > `std::move(**this)` is used instead of `std::move(value())`. Maybe this is > an oversight/inconsistency of the standard.) Yes. The spec were written by different people at different times.
[Bug libstdc++/109947] std::expected monadic operations do not support move-only error types yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109947 --- Comment #3 from Martin Seemann --- Thanks for pointing me to the LWG issue. It makes sense that the error type must be copyable for the `value()` overloads due to potentially throwing a `bad_expected_access` with the embedded error embedded. However, the monadic operations will never throw this exception. Consequently, the standard draft for the monadic operations (https://eel.is/c++draft/expected.object.monadic) does not contain any "Throws:" clause nor is copyability of the error type included in the "Constraints:" clause. So it comes down to how to interpret the "Effects:" clause: Does "Equivalent to " mean that all restrictions of `value()` apply transitively or is it merely an implementation hint? (Strangely enough, in the "Effects:" clause of `value_or()&&` the expression `std::move(**this)` is used instead of `std::move(value())`. Maybe this is an oversight/inconsistency of the standard.)
[Bug libstdc++/109947] std::expected monadic operations do not support move-only error types yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109947 --- Comment #2 from Jonathan Wakely --- To be clear, a move-only value type is OK. A move-only error type is not.
[Bug libstdc++/109947] std::expected monadic operations do not support move-only error types yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109947 --- Comment #1 from Jonathan Wakely --- (In reply to Martin Seemann from comment #0) > GCC13 introduce monadic operations for `std::expected`, including r-value > ref-qualified overloads, which suggests that it should be possible to use an > expected with a move-only value or error type. No, see https://cplusplus.github.io/LWG/issue3843
