CWG3130 [expr.prim.id.general] Naming function members of anonymous unions after P2996 Reflection

[hubert-reinterpretcast]

Full name of submitter (unless configured in github; will be published with the issue): Hubert Tong

Reference (section label): [expr.prim.id.general]

Link to reflector thread (if any): N/A

Issue description:

https://wg21.link/expr.prim.id.general#3 leaves the meaning of id-expression‌s that denote function members of namespace-scope anonymous unions in a black hole as the applicable bullet assumes that a member of an anonymous union variable is necessarily a data member.

Special member functions of an anonymous union type are observable via reflection, however, implementations are still behind (https://godbolt.org/z/T5GTqcx58):

#include <meta>
using namespace std::meta;

static union { int x; };

constexpr info anon_union = parent_of(^^x);
static_assert(is_type(anon_union));

using AnonUnion = [:anon_union:];
using AUOpAssignType = AnonUnion &(AnonUnion &&);
using AUOpAssignMPTy = AUOpAssignType AnonUnion::*;

namespace idexpr {
AUOpAssignMPTy aumemptr = &AnonUnion::operator=;
}

namespace extractcall {
constexpr info au_mem = members_of(anon_union, access_context::unchecked())[5];
//static_assert(0, display_string_of(au_mem));
auto aumemptr = extract<AUOpAssignMPTy>(au_mem);
}

Suggested resolution:

Scope the subject paragraph to apply only to id-expression‌s denoting data members.

[hubert-reinterpretcast]

Ping @jensmaurer.

[jensmaurer]

Did you mean something like this?

CWG3130

[hubert-reinterpretcast]

Did you mean something like this?

I think we can change it as follows (unless we really mean for it to be possible to name the function as a member of an enclosing class as in https://godbolt.org/z/183EEsT3a):

If an id-expression E denotes a variant member M of an anonymous union (11.5.2 [class.union.anon]) U:

However, it seems the scope of the problem is a bit larger.

There are some "obvious problems":

• The definition of direct member makes these special member functions of an anonymous union class direct members of an enclosing class (https://wg21.link/class.mem.general#3).
• The names of these special member functions are apparently bound to an outer scope (https://wg21.link/class.union.anon#1).

There are also some "less obvious problems":

• It is unclear whether the prohibition on pointer-to-member-of-anonymous-union types (https://wg21.link/dcl.mptr#2) was established with awareness about function members of anonymous union classes. I believe the prohibition makes it impossible to use extract on a reflection value that represents such a function.
• Similarly, https://wg21.link/expr.unary.op#3.1 needs another look.

[jensmaurer]

I'm wondering whether the definition of "direct member of class C" should be changed to exclude members of an anonymous union declared inside C. It seems some places talking about functions would be unaffected, some places in access control would need massaging (or a new defined term), and some places would actually benefit.

Should anonymous unions have special member functions of their own to start with? Maybe those should simply not exist at all (not even implicitly declared ones). Everything is handled by the surrounding class anyway. That would solve a lot of issues in that area, I think.

[hubert-reinterpretcast]

I'm wondering whether the definition of "direct member of class C" should be changed to exclude members of an anonymous union declared inside C. It seems some places talking about functions would be unaffected, some places in access control would need massaging (or a new defined term), and some places would actually benefit.

I think https://wg21.link/class.base.init#2 relies on the current definition. I am not sure what places (aside, perhaps, from reflection-related wording) would benefit if the function cases are handled in some other manner.

Should anonymous unions have special member functions of their own to start with? Maybe those should simply not exist at all (not even implicitly declared ones). Everything is handled by the surrounding class anyway. That would solve a lot of issues in that area, I think.

I agree except for the question of how reflection code is meant to deal with anonymous unions. If reflection gives rise to lvalue expressions of the anonymous union class type, should it be made possible for those to be assigned to as a union?

[jensmaurer]

I think https://wg21.link/class.base.init#2 relies on the current definition.

... except that it does not actually use the term "direct member" currently; it uses (incorrectly) "a ... member of the constructor's class" without "direct". That's a separate bug, though.

I agree except for the question of how reflection code is meant to deal with anonymous unions. If reflection gives rise to lvalue expressions of the anonymous union class type, should it be made possible for those to be assigned to as a union?

I think the answer is "no". Those things simply have no special member functions (of their own), so the overload resolution inherent in copy-construction and copy-assignment would come up empty, causing an ill-formed program. Similarly, there is no default constructor, so you can't default construct those.

This seems to be one of those cases where CWG comes up with a design and asks for an EWG nod.

[hubert-reinterpretcast]

I think the answer is "no". Those things simply have no special member functions (of their own), so the overload resolution inherent in copy-construction and copy-assignment would come up empty, causing an ill-formed program. Similarly, there is no default constructor, so you can't default construct those.

This seems to be one of those cases where CWG comes up with a design and asks for an EWG nod.

I think the direction is worth exploring, but making "anonymous unions" even more special should probably come with a type trait/reflection query at the same time. @katzdm, @daveedvdv, @brevzin, thoughts?

[katzdm]

I think the answer is "no". Those things simply have no special member functions (of their own), so the overload resolution inherent in copy-construction and copy-assignment would come up empty, causing an ill-formed program. Similarly, there is no default constructor, so you can't default construct those.
This seems to be one of those cases where CWG comes up with a design and asks for an EWG nod.

I think the direction is worth exploring, but making "anonymous unions" even more special should probably come with a type trait/reflection query at the same time. @katzdm, @daveedvdv, @brevzin, thoughts?

The direction seems fine to me. Named unions will continue to have constructors, right?

Note that anonymous unions can be recognized by way of is_union(R) && !has_identifier(R) - not sure whether a special type trait is needed or not (but I'm not opposed).

[hubert-reinterpretcast]

Note that anonymous unions can be recognized by way of is_union(R) && !has_identifier(R) - not sure whether a special type trait is needed or not (but I'm not opposed).

From the 2025-11-21 CWG telecon:
union { int x; } u; will generate a "false positive" for the above query.

From further conversation with @katzdm:
We can restrict creation of "novel" objects of anonymous union class types by adding:

All objects of such an unnamed type shall be such an unnamed object.

as the second sentence of https://wg21.link/class.union.anon#1 (where the first sentence defines the terms anonymous union member and anonymous union variable).