P3612R1 Harmonize proxy-reference operations

[AlisdairM]

Fixes #8471
Fixes cplusplus/papers#2419

[AlisdairM]

I would like to create a new subsection for each nested reference class to avoid the need to qualify each \itemdecl with the unusual reference:: qualifier, and also to better organize these specifications out of appearing out of nowhere in the surrounding text that is talking about the surrounding class as a whole before specifying its own members in following subclauses.

[eisenwave]

Suggested change

	constexpr reference(const reference&) noexcept;
	constexpr reference(const reference& x) noexcept;

The paper adds an x here.

[eisenwave]

Suggested change

	constexpr reference(const reference&) noexcept;
	constexpr reference(const reference& x) noexcept;

There is also no x in the paper though. However, the paper does add an x in the synopsis of bitset::reference, and the whole point is harmonization, so I guess there ought to be an x here.

[jwakely]

I agree with Jan's two suggestions.

[AlisdairM]

Fixed, plus applied the noted editorial comment in the paper to reorder the members consistently. In doing so, I noticed that only bitset::reference has a unary operator~, and worse, it remains unspecified.

Should we open an LWG issue to add that specification, and following the harmonization principle, add the same to vector<bool>::reference?

[jwakely]

I noticed that only bitset::reference has a unary operator~, and worse, it remains unspecified.

Should we open an LWG issue to add that specification, and following the harmonization principle, add the same to vector<bool>::reference?

We should definitely not add it to vector bool. See the LWG mattermost on October 9 where @Bekenn observed:

I see that paper leaves the bitset's reference::operator~ intact; that function should be removed (or at least deprecated).

With an actual bool, the value is promoted to int prior to the application of the ~ operation. This means that, for instance, ~true comes out as -2, not false.

i.e. static_assert( ~false && ~true ) passes with the core language, so I don't think ~bitref is a useful operator.

Resolved.