Implement P3612R1 Harmonize Proxy-Reference Operations
Add friend swap functions to std::bitset<N>::reference and std::vector
Resolves #5842
Resolves #5842
There is a constexpr const reference& operator=(bool x) const noexcept in std::vector<bool>::reference since P2321 but it was wrapped by _HAS_CXX23. I have removed the conditional compilation, as I've understood that we want to include this paper's modifications unconditionally and this specific assignment operator overload is required to comply with
If cr is of type const Reference, then cr = cr2 will end up calling cr.operator=(bool(cr2)), which is fine.
(https://isocpp.org/files/papers/P3612R1.html#background , paragraph 4)
Please confirm this change is OK as well (not doing it would be against the intent of the paper though as there would be an API difference between both proxy types).
Making that unconditional sounds correct to me.
By the way, please edit your original PR description to say "Resolves #nnnn". Only PR descriptions can set up the auto-resolve links with the magic phrases. In ordinary comments, the magic words are ignored and you just get a "mention" cross-reference.
By the way, please edit your original PR description to say "Resolves #nnnn". Only PR descriptions can set up the auto-resolve links with the magic phrases. In ordinary comments, the magic words are ignored and you just get a "mention" cross-reference.
Done, I hope it's correct now.
It is now failing because of tests of the static vector<bool>::swap(reference, reference). Any advise on prefered resolution method? Whether to silence the deprecation warning for the test.cpp or to remove the offending line and never invoke the static swap in tests.
Typically we define the silencing macro at the top of a test that has to exercise it. Search for the other deprecation macros for precedent.
Oh, and please validate your changes with a local test run for any updated/affected tests, before pushing changes. This is both faster for you to iterate with, and avoids unnecessarily consuming the CI machines which are a shared resource. It's okay if everything looks fine with the limited set of tests you ran, and then you push and discover newly affected tests, but the initial local run will help avoid a lot of unnecessary delay.
Oh, and please validate your changes with a local test run for any updated/affected tests, before pushing changes. This is both faster for you to iterate with, and avoids unnecessarily consuming the CI machines which are a shared resource. It's okay if everything looks fine with the limited set of tests you ran, and then you push and discover newly affected tests, but the initial local run will help avoid a lot of unnecessary delay.
Yes, of course, I unfortunately run only std, hence I missed those two failing tests (one in libcxx and one in tr1).. Apologies for failed CIs..