P3612R1 Harmonize Proxy-Reference Operations

[StephanTLavavej]

WG21-P3612R1 Harmonize Proxy-Reference Operations

No feature-test macro is mentioned.

This resolves: LWG-3638 vector<bool>::swap(reference, reference) is useless LWG-4187 bitset::reference should be const-assignable

This deprecates vector<bool>::swap(reference, reference), but as Wakely argued, it "is not useful. Nobody calls swap like that." As this simply resolves LWG issues and doesn't take any top-level names, I believe we should implement this unconditionally, and I'm willing to review a PR for it before opening up the general C++26 floodgates.

[vmichal]

Hi, I would like to work on this issue; it seems reasonably small.

Unfortunately, I can't access the link https://wg21.link/P3612R1 you have provided. I can access only R0 of the paper (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3612r0.html). Is it possible it is behind some authentication barrier?

In the meantime, I will implement R0 (hoping changes will be minimal). Since std::vector<bool>::swap(reference, reference) is deprecated by the paper, can I create a new deprecation warning and increment the // next warning number: STL4049 counter in yvals_core.h?

Thanks

[vmichal]

Also, regarding tests, should I create an entirely new test in a new directory, or do you prefer to augment (or reuse) existing tests? For example, std/tests/Dev10_816787_swap_vector_bool_elements seems like a natural candidate to extend.

[cpplearner]

Unfortunately, I can't access the link https://wg21.link/P3612R1 you have provided. I can access only R0 of the paper (https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3612r0.html). Is it possible it is behind some authentication barrier?

You can find P3612R1 at https://isocpp.org/files/papers/P3612R1.html.

[StephanTLavavej]

Yeah, it takes a while for papers to be officially published and for the wg21 link redirector to be updated, thanks @cpplearner for the workaround.

Since std::vector<bool>::swap(reference, reference) is deprecated by the paper, can I create a new deprecation warning and increment the // next warning number: STL4049 counter in yvals_core.h?

Yep, that's the correct approach.

Also, regarding tests, should I create an entirely new test in a new directory, or do you prefer to augment (or reuse) existing tests? For example, std/tests/Dev10_816787_swap_vector_bool_elements seems like a natural candidate to extend.

Yep, let's extend that old test.

In general, new tests for new large features are appropriate, but for something small, if there's an existing test that's in a very similar area, and it doesn't have exotic configurations in its env.lst, then extending that test is entirely reasonable. We usually comment the added coverage with the paper number/title as a reminder of what it's testing.

(There is some test-runtime cost for every directory, so having tons of microscopic tests is undesirable from that perspective.)