-
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
LWG-2774 std::function
construction vs assignment
#2098
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Compile-only tests should be test.compile.pass.cpp
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should also edit the file: https://github.com/Microsoft/STL/blob/main/tests/std/test.lst
(add tests\LWG2774_function_construction_vs_assignment
)
It appears that the following somehow became true when it's supposed to be false: static_assert(is_constructible_v<decay_t<_Fx>, _Fx>, "decay_t<F> shall be constructible with F"); However, if I pass in a void test() {
const Fn fn;
function<void()> f{fn}; // fail to compile here because of the assertion
} I am unsure how this can be... EDIT: Oh, maybe since the compiler technically found a candidate (not at the assertion yet), |
yes, you are correct: |
I am making this a draft right now as there seems to be no way of testing a valid instantiation with failed assertion (the detector pattern implemented is currently malfunctional too). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. It looks like we really can't create tests for that.
Thanks - and sorry again for taking so long to get to this 😿. Your changes are completely correct as far as I can tell 😻, so to move this forward to Final Review I've pushed a merge with |
I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed. |
Thanks for improving |
…ven after LWG-2774 [LWG-2774](https://wg21.link/lwg2774) changes `std::function`'s converting constructor to accept its argument by forwarding reference. With that change implemented, that constructor becomes a better match for non-`const` `unique_function` arguments than `unique_function`'s `const`-qualified deleted conversion operator template to `std::function`. As a result, `std::is_convertible_v<unique_function<T>, std::function<T>>` changes from `false` to `true` when Standard Libraries implement LWG-2774. (MSVC recently implemented this LWG issue in microsoft/STL#2098 and noticed the `unique_function` test failing as a result.) I believe the fix is to add another deleted conversion operator template that is not `const`-qualified to `unique_function`. This makes the test pass locally, as well as correcting a simplified test case with GCC trunk (microsoft/STL#2098) which I believe also implements LWG-2774.
…::function` even after LWG-2774 [LWG-2774](https://wg21.link/lwg2774) changes `std::function`'s converting constructor to accept its argument by forwarding reference. With that change implemented, that constructor becomes a better match for non-`const` `unique_function` arguments than `unique_function`'s `const`-qualified deleted conversion operator template to `std::function`. As a result, `std::is_convertible_v<unique_function<T>, std::function<T>>` changes from `false` to `true` when Standard Libraries implement LWG-2774. (MSVC recently implemented this LWG issue in microsoft/STL#2098 and noticed the `unique_function` test failing as a result.) I believe the fix is to add another deleted conversion operator template that is not `const`-qualified to `unique_function`. This makes the test pass locally, as well as correcting a simplified test case with GCC trunk (microsoft/STL#2098) which I believe also implements LWG-2774. Closes #1437 Signed-off-by: Blake Oler <[email protected]> and Billy Donahue <[email protected]>
Partially addresses #1965