-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
<future>
: Make packaged_task
accept move-only functors
#4946
<future>
: Make packaged_task
accept move-only functors
#4946
Conversation
dce03b0
to
5195dd0
Compare
I think it worth creating vNext issue.
|
Or maybe |
This comment was marked as off-topic.
This comment was marked as off-topic.
N.B. I'm proposing to restore |
and merge `_Packaged_state` specializations
Thanks @jwakely! BTW, in this repo's issues you can say LWG-4158 with a dash to use the autolink syntax we've set up - no need to manually craft hyperlinks. (https://github.com/microsoft/STL/wiki/Custom-Autolinks has the full list.) |
Thanks for the extremely careful work! 😻 |
I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed. |
VSO-2279389 "/clr C++20 can't handle struct MoveOnlyFunctor defined in a function template, emitting fatal error C1193: an error expected in yyaction.cpp(2899) not reached"
I pushed a commit to perma-workaround VSO-2279389 " |
Thanks for fixing this impossible bug! 🐞 ✅ 😻 |
#5009 is created for tracking. |
Fixes #321.
The issue was considered ABI-breaking, but I think it can be resolved in an ABI-preserving way like #2568. This PR adds internal constructors to
function
to accept non-copy-constructible functors and addstatic_assert
to keep the copyability checking for standard constructors. Valid user codes won't be able to call these internal constructors.Also implements the previously missing Mandates in [futures.task.members]/3, and switches to use move construction in
reset
per [futures.task.members]/26.Notes:
function
.function<R(Args...)>
is a program-defined specialization, this approach doesn't work. I don't think any user should specializestd::function
, but this is allowed by the standard._Packaged_state
specializations are merged into one. I believe this can ease maintenance.