Skip to content

Conversation

@AlisdairM
Copy link
Contributor

Fixes #8471

@AlisdairM
Copy link
Contributor Author

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.

class reference {
public:
constexpr reference(const reference&) = default;
constexpr reference(const reference&) noexcept;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

The paper adds an x here.

class @\libmember{reference}{vector<bool>}@ {
public:
constexpr reference(const reference&) = default;
constexpr reference(const reference&) noexcept;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@eisenwave eisenwave added this to the post-2025-11 milestone Nov 25, 2025
Copy link
Member

@jwakely jwakely left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with Jan's two suggestions.

@AlisdairM AlisdairM force-pushed the p3621r1_harmonize_proxy_refs branch from af003f3 to 8090054 Compare November 28, 2025 03:25
@AlisdairM
Copy link
Contributor Author

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?

Reorder the members of `reference` classes to be consistent with each other
and elsewhere.  First list constructors, destructor, and assignment operator.
Then list accessors, and finally modifiers. Keep unary `operator~` adjacent
to `flip` where both are present.
@AlisdairM AlisdairM force-pushed the p3621r1_harmonize_proxy_refs branch from 8090054 to 54f76fc Compare November 28, 2025 03:43
@jwakely
Copy link
Member

jwakely commented Nov 28, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[2025-11 LWG Motion 12] P3612R1 Harmonize proxy-reference operations (LWG 3638 and 4187)

3 participants