<expected> Implement P0323R12

[Michael Schellenberger Costa (miscco)]

This implements <expected> that has been added by P0323R12.

I have also incorporated the changes from WG21-P2549.

I might have been a bit too strict with constraints.

Fixes #2529

[Alex Guteniev (AlexGuteniev)]

Have you considered empty object optimization for Empty unexpected class?

[Michael Schellenberger Costa (miscco)]

Have you considered empty object optimization for Empty unexpected class?

You mean in the case expected<void, empty>?

[Alex Guteniev (AlexGuteniev)]

Have you considered empty object optimization for Empty unexpected class?

You mean in the case expected<void, empty>?

Yes, and also expected<int, empty>.

[Michael Schellenberger Costa (miscco)]

Have you considered empty object optimization for Empty unexpected class?

You mean in the case expected<void, empty>?

Yes, and also expected<int, empty>.

But the second one would not benefit from any empty base class optimization as we still have to allocate the value of T.

Also this essentially doubles the implementation size because we still have to do a lot of things. E.g. just because a type is empty does not mean its construction is trivial. So we would need to still keep a lot of the implementation.

I think if the maintainers really want to one could do it but the gains seem questionable.

[Stephan T. Lavavej (StephanTLavavej)]

Thanks! Video code review pending. 😸

Note to self: I still need to review <expected> starting at class expected, and the new test.cpp.

[Stephan T. Lavavej (StephanTLavavej)]

I've pushed one more change thanks to A. Jiang (@frederick-vs-ja)'s discovery in #2733 that cplusplus/draft#5381 has patched expected::error() to always be noexcept in the Standard (for both the primary template and void specialization).

[Stephan T. Lavavej (StephanTLavavej)]

Alex Guteniev (@AlexGuteniev) Thanks for raising the Empty Base Class Optimization question (in #2643 (comment) etc). I agree with Michael Schellenberger Costa (@miscco) that the implementation complexity would be high and the benefits would be minimal. Specifically, only the following cases would benefit:

• expected<EmptyType, EmptyError>
• expected<void, EmptyError>

In these cases, we could reduce the representation from 2 bytes (empty union followed by bool) to 1 byte (just the bool). Although it halves the space consumption, these scenarios seem quite unlikely. expected is useful when the error type contains a "reason". If it's an empty error type, it's just signaling its presence, so expected<Anything, EmptyError> provides little value over optional<Anything> (either you have the result or you don't), and expected<void, EmptyError> is basically a bool (did you succeed or fail - expected is slightly less ambiguous, but an enum class Result : bool { Failure, Success }; would avoid ambiguity.

Unlike empty allocators, empty comparators, empty function objects, etc. I think that the EBCO isn't worth the implementation complexity, throughput cost, and risk here.

[Stephan T. Lavavej (StephanTLavavej)]

I'm speculatively mirroring this to the MSVC-internal repo - further changes can be pushed, but please notify me.

[Stephan T. Lavavej (StephanTLavavej)]

I had to push an additional change to work around VSO-1543660 "Standard Library Header Units: <expected> ICEs with Assertion failed: IsInClassDefn()" by disabling the use of <expected> in that test. Additionally, I have renamed expected local variables to avoid shadowing when the test coverage is restored (interestingly, merely import <expected>; followed by such shadowing variables was causing the ICE).

[Casey Carter (CaseyCarter)]

Reviewed product code only. I'm now going to review the test code, after which I'll prepare changes for my comments if nobody has commented otherwise. (I'm trying to avoid digging through 175 comments to see if any of these have already been rejected, but I'll probably dig through anyway before I push.)

[Michael Schellenberger Costa (miscco)]

I would have preferred to have this as part of the assignment tests but meh...

[Stephan T. Lavavej (StephanTLavavej)]

I have pushed a (hopefully final) commit to guard/optimize destruction as noticed by Michael Schellenberger Costa (@miscco), and to enable internal coverage for the header units test now that Cameron DaCamara (@cdacamar) has fixed the bug 🎉 🐞.

[Stephan T. Lavavej (StephanTLavavej)]

Thanks for implementing this major C++23 feature - it's expected to be a popular one! 😹 😻 🎉