Enhancements for future and shared_future
#3284
Conversation
Add noexcept to _Deleter_base::_Delete, _State_deleter::_Delete, _Retain, and_Release.
strega-nil-ms
left a comment
There was a problem hiding this comment.
LGTM, thanks so much!
In constructors we can expect that `this != _STD addressof(_Other)`, so the refactorization seems worthy.
CaseyCarter
left a comment
There was a problem hiding this comment.
These are suggestions rather than requirements, so I'll go ahead and approve.
|
Thanks - this is riskier than the average PR, but I think it preserves ABI and is a worthy improvement. I've pushed a couple of tiny changes to the test - a trivial naming nitpick (which I wouldn't have bothered with by itself), and a line to verify that the empty-braces type trait can report both |
|
I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed. |
|
Thanks for noticing the nonconformance here and carefully improving things! 🕵️ 😻 ✨ |
This PR is making some enhancements for
<future>.std::is_nothrow_move_assignable_v<std::shared_future<void>>isfalsein MSVC STL (Godbolt link), which is non-conforming. This PR fixes this bug by making internal functionsnoexcept(inspired by Mark constructors that do not throw exceptions as noexcept #3278) and some special member functions defaulted.std::future<T> ft(another_future, {});(whereanother_futureis of typestd::future<T>orstd::shared_future<T>) (Godbolt link). This PR forbids such definitions - because I think the internal constructors shouldn't be directly touched when no _Ugly name is explicitly specified, although the status quo is conforming due to [member.functions]/2._Copy_fromand_Move_fromof_State_managerinto constructors and assignment operators, and simply the codes - this is making the implementation code shorter.