LWG-2774 std::function construction vs assignment - #2098
Conversation
Igor Zhukov (fsb4000)
left a comment
There was a problem hiding this comment.
Compile-only tests should be test.compile.pass.cpp
There was a problem hiding this comment.
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). |
Igor Zhukov (fsb4000)
left a comment
There was a problem hiding this comment.
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 <blake.oler@mongodb.com> and Billy Donahue <billy.donahue@mongodb.com>
Partially addresses #1965