1 Abstract

We propose two minor design changes to [P2996R12] to ensure its readiness for C++26 and future-proof the evolution of the feature.

First, we propose that “splice template arguments” be removed from P2996 and deferred until C++29: Neither the wording nor the implementation are fully baked, CWG has not (as of this writing) dedicated sufficient time to its review, and Reflection suffers no loss of expressive power from its removal.

Second, in response to edge cases surfaced during CWG review, we elaborate on the need to represent using-declarations with Reflection. At this late stage, we offer two means of ameliorating this feature’s absence:

1. Permit a narrow expansion of scope to what is already offered by P2996 by introducing reflections of using-declarations to C++26, or
2. Make ^^Cls::mem ill-formed whenever mem names a using-declaration, thus preserving the syntactic space for C++29.

2 Background

2.1 Removing splice template arguments

2.1.1 Refresher: What are “splice template arguments”?

P2996 proposes splice-template-arguments that can match any other kind of template argument. For instance, given

template <class P1, auto P2, template<typename> class P3>
struct mytemplate;

the template-id

mytemplate<[:R1:], [:R2:], [:R3:]>

will be valid as long as the constructs represented by R1, R2, and R3 match the form of the respective template parameters.

2.1.2 Would removing this mean that I can’t use splices as template arguments?

No. An expression splice (i.e., splice-expression) can appear as a constant template argument, and a type splice (i.e., splice-type-specifier) can appear as a type template argument.

constexpr auto r1 = ^^int;
constexpr auto r2 = std::meta::reflect_value(42);

std::array<typename [:r1:], [:r2:]> arr;  // OK

Splice template arguments, the feature that we here propose to remove from P2996, lets the syntax [:R:] uniformly match any kind of template parameter when appearing in a template argument list. So while the above example remains valid, the following become disallowed because (in the absence of “splice template argument” support) unqualified [:R:] always parses as an expression:

std::array<typename [:r1:], [:r2:]> arr1;
  // still OK
std::array<[:r1:], [:r2:]> arr2;
  // error: reflection of a type 'r1' cannot splice as an expression; did you mean 'typename [:r1:]'?
  // error: cannot splice 'r1' (a reflection of a type) as an expression
  // error: expression '[:r1:]' does not match template type parameter

template <template <typename T, int V> class Tmp, typename T, int V>
auto make() { return Tmp<T, V>{}; }

constexpr std::meta::info rs[] = {^^std::array, ^^int, std::meta::reflect_value(42)};

auto arr = make<[:rs[0]:], [:rs[1]:], [:rs[2]:]>();
  // error: expression '[:rs[0]:]' does not match template template parameter 'Tmp'
  // error: expression '[:rs[1]:]' does not match type template parameter 'T'

2.1.3 Why defer to C++29?

Consider the following example:

template <template <typename> class TCls>
auto tfn1() {
  return TCls<int>{};
}

template <std::meta::info R>
template tfn2() {
  return tfn1<[:R:]>();
}

For the template-id tfn1<[:R:]> to be valid in the template definition of tfn2(), we must be able to substitute the dependent splice template argument [:R:] into tfn1. In the parlance of P2996, this entails replacing the template-id “TCls<int>” with the splice-specialization-specifier “[:R:]<int>”, and replacing the template-name “TCls” with the splice-specifier “[:R:]”.

Since Clang implements template substitution as a tree transformation (i.e., “recursively substitute like things with like things”), the Clang reference implementation of P2996 handles this by adding a new category of DependentTemplateName in which a TemplateName wraps a SpliceSpecifier.

This implementation strategy mirrors the grammar proposed by [P2996R7], in which a template-name might be a splice-specifier. Discussion within CWG, however, steered us away from this direction (for good reason: a splice-specifier is not a “name”). The primary author of the Clang/P2996 reference implementation has not identified a suitable alternative implementation strategy, reinforcing the belief that splice template arguments, as currently specified, require a tighter coupling of template-name and splice-specifier. As tempting as it is to dismiss this as “just a wording problem”, the wording strategy is not easily separable from the implementation strategies that will be adopted by compilers.

Lastly, as of this writing, CWG is yet to invest meaningful time in the review of splice-template-arguments. The combination of our belief that the wording is insufficient, together with the scrutiny that the feature still requires, leaves us feeling that dropping the feature from P2996 will strengthen P2996’s readiness for C++26.

2.1.4 What power is lost from P2996?

Absolutely none. Any template-id written with splice-template-arguments as

template_name<[:R1:], [:R2:], [:Rs:]...>

can be equivalently expressed using std::meta::substitute:

[:substitute(^^template_name, {R1, R2, Rs...}):]

Splitting splice template arguments from the paper, therefore, represents a means of reducing the P2996 surface area that CWG still needs to review, while losing absolutely no expressive power from P2996.

2.1.5 Can we add this later?

Absolutely. For C++26, a template argument of the form [:R:] will always be considered a splice-expression, which can only match a constant template parameter. In C++29, we can make it well-formed for this syntax to also match type template parameters and template template parameters.

That said, the change will not be entirely non-breaking; consider the following example provided by Tomasz Kamiński:

template <auto>     int foo();  // A
template <typename> int foo();  // B

template <std::meta::info R>
auto bar(int) -> decltype(foo<[:R:]>()) { return 1; }  // #1

template <std::meta::info R>
auto bar(...) -> int                    { return 0; }  // #2

constexpr int v = bar<^^int>(1);

In the initializer for v, bar denotes an overload set containing both #1 and #2. Function template argument deduction for #1 will fail, since the substitution of “^^int” into “R” will form “[:^^int:]” - an invalid splice-expression. Since this ill-formed expression is within the immediate context, the specialization will merely be discarded from the set of candidate functions. We are left with the specialization derived from #2, within which no such ill-formed expression appears; v is initialized to 0.

But in the presence of splice template arguments, “[:^^int:]” is parsed as a splice-template-argument rather than an expression. The non-dependent splice-template-argument is interpreted as a splice-type-specifier, so the B overload is selected. Because #1 is a better match than #2, v would initialized to 1.

WG21 has historically found changes to overload resolution to be acceptable, even when it has meant breaking SFINAE-dependent programs. We therefore feel that the suggestion to adopt splice template arguments later rests on solid ground - but it’s certainly still worth pausing to understand the implications.

2.1.6 What if we want to keep it?

Risky, but also not the end of the world. The grammar for template-name ([temp.names]) will likely have to be extended:

Which is not only an invasive change, but one that CWG has judged to be ill-advised. The P2996 authors will have to (again) comb through the corpus of core wording to find what other sections must be modified to account for the change, while adding various “if the template-name is an identifier” carve outs for cases where the template-name is more “name”-like than “computed entity specifier”-like. It is the opinion of the authors that further substantial core wording homework would neither be beneficial to the prospects of Reflection making C++26 nor to their emotional well-being.

2.2 The necessity of reflecting using-declarations

2.2.1 Motivation

Consider the following example:

struct Base { int member = 0; };
struct Derived : private Base { using Base::member; };

Derived d;
auto p1 = d.member;  // OK
auto p2 = d.[:^^Derived::member:];   // error

Consider also the following assertions, which all hold with [P2996R12]:

#include <meta>

struct Base {
  protected: int member;
  friend void fn();
};

struct Derived : private Base {
  using Base::member;
};

void fn() {
  constexpr auto ctx = std::meta::access_context::unprivileged();
  static_assert(!is_accessible(^^Base::member, ctx));
  static_assert(!is_accessible(^^Derived::member, ctx));
  static_assert(!is_accessible(^^Base::member, ctx.via(^^Derived)));
  static_assert(!is_accessible(^^Derived::member, ctx.via(^^Derived)));
}

auto p = &Derived::member;  // no problem

In particular, there is currently no way to observe

1. That the using-declaration naming Base::member exists in the scope of Derived or
2. That Base::member can be accessibly named in the scope of Derived.

The first point implies restrictions for e.g., debug tools that may wish to format a representation of a class type. The second implies a limited view of which members are accessible within a class.

2.2.2 What? Why?!

In both examples above, the expression ^^Derived::member represents the entity Base::member because using-declarations are transparently replaced with the declarations that they name during lookup ([basic.lookup]/3). In the first example, the expression

d.[:^^Derived::member:]

is ill-formed because the type of the left-hand-side (i.e., Derived &) cannot be converted to the “naming class” of the right-hand-side (i.e., Base) ([class.access.base]/6); since ^^Derived::member represents Base::member, this is the moral equivalent of writing d.Base::member. Similarly in the second example, the expression

is_accessible(^^Derived::member, ctx.via(^^Derived))

asks whether the class member Base::member is accessible from a point in the global scope when named in the class Derived. The algorithm from [class.access.base]/5 tells us that this is not the case, which mirrors the fact that writing Derived::Base::member is ill-formed. If we want to instead determine whether Derived::member is well-formed, we must instead ask whether the using-declaration is accessible in Derived, a question which P2996 lacks the machinery to model.

2.2.3 Why was this not in P2996R0 or P2996R1 or P2996R2 or …?

During early revisions of P2996, the authors did not seek to integrate Reflection with Access Control. Around the time of the Wrocław meeting, it became more clear that a robust story for observing the accessibility of class members would be required to achieve consensus for the design. The direction proposed by [P3547R1] received strong support in Hagenberg, and was thereafter merged into [P2996R10].

using-declarators, as currently specified, are not a natural target for Reflection: Since they introduce only names (rather than entities or class members), there is “nothing to reflect” (in this regard, they are more similar (pre-P2996) to type aliases and namespace aliases than to e.g., non-static data members). They nevertheless play an important role in Access Control: An otherwise inaccessible member of a base class might be accessible when named through a using-declarator declared in a derived class (see [class.access.general]/4).

The surprising behavior exhibited by the first example, in which the “surprising answer” is obtained using only the reflection and splicing operators, was only very recently uncovered by a careful review of [expr.ref] and [class.access] during CWG review.

2.2.4 How should this be handled?

What follows is a small extension on top of what is proposed by P2996. We provide it as an elaboration of how we believe Reflection should interact with using-declarations in an unspecified future delivery vehicle of the C++ Standard.

• First, we propose modifying the core wording around using-declarators such that they do introduce entities (analogous to existing changes in P2996 for type aliases and namespace aliases). In particular a declaration

  class Cls {
    using Scope::id;
  };

  introduces a class (or namespace) member known as an entity proxy for each entity whose declaration is named by Scope::id (note: several such members may be introduced if Scope::id denotes an overload set). The “underlying entity” of each such entity proxy is one of the entities whose declarations were named by Scope::id. Note that this is scarcely more than a technical wording change to make sure there is “something to have a reflection of”.

• Next, we propose that a reflect-expression ^^Cls::id whose operand names a unique entity proxy, represents said entity proxy, and not its underlying entity. This gives a means of observing the properties of the entity proxy (e.g., accessibility, parent class) apart from the properties of its underlying entity.

• Since entity proxies are members of classes and namespaces, we propose that the reflections returned by members_of also include entity proxies (i.e., in formal P2996 parlance: entity proxies that are members of a class or namespace Q are Q-members-of-representable).

• If lookup for Cls::id finds multiple declarations named id in the scope of Cls, the reflect-expression ^^Cls::id is ambiguous and ill-formed, even if all such declarations denote the same underlying entity.

  class A { void fn(); };
  class B : virtual A { using A::fn; };
  class C : virtual A { using A::fn; };
  class D : B, C {};
  
  auto p = &D::fn;  // OK
  constexpr auto r = ^^D::fn;  // ambiguous, ill-formed

  In a more distant future, it may be possible to let such expressions represent all entities named by the ambiguous lookup; this direction would take advantage of how Reflection separates the lookup of a name from its point of use. Such “lookup sets” could be a powerful extension that facilitates (and generalizes) overload sets.

• Existing P2996 metafunctions would be updated to observe properties of entity proxies (e.g., is_public, parent_of, is_class_member), and a new is_entity_proxy function would be introduced to recognize such reflections.

• Lastly, the P2996 metafunction std::meta::dealias should map a reflection of an entity proxy to a reflection of its underlying entity. Since the phrase “underlying entity” is a Word of Power introduced by P2996 that applies equally well to aliases and entity proxies, we propose renaming std::meta::dealias to std::meta::underlying_entity_of. A separate std::meta::proxied_entity_of function returns a reflection of the entity directly named by an entity proxy without “unwrapping all layers” to reach the underlying entity.

  class B { using Alias = int; };
  class D : B { using B::Alias; };
  
  static_assert(is_type_alias(^^B::Alias));
  static_assert(is_entity_proxy(^^D::Alias));
  static_assert(^^B::Alias != ^^D::Alias);
  static_assert(proxied_entity_of(^^D::Alias) == ^^B::Alias);
  static_assert(underlying_entity_of(^^D::Alias) == ^^int);
  static_assert(underlying_entity_of(^^B::Alias) == underlying_entity_of(^^D::Alias));

2.2.5 Can this all wait until C++29?

Given the following code:

struct A { protected: int m; };
struct B : private A { using A::m; };

constexpr auto rm = ^^B::m;

We must decide now whether ^^B::m

• represents the member A::m that is a member of A (P2996 status quo),
• represents a member B::m that is a member of B and whose underlying entity is A::m (as elaborated above), or
• is ill-formed.

That decision will be observable to programs in several ways (e.g., whether parent_of(rm) is ^^B or ^^A, the result of is_public(rm), etc). If we would prefer that ^^B::m instead represent a member of B, we should either adopt that change now or make the expression ill-formed entirely to reserve space for that change in C++29. Either way, we should make that change for C++26.

2.2.6 What else can we do with entity proxies?

Although the “generative metaprogramming” facilities directly provided by P2996 will be narrow (e.g., define_aggregate), it will be possible to inspect the members and properties of a class, compute a string containing a well-formed C++ class definition derived from that class, render that string to stdout, and write the resulting code to a file or a pipe to another process (e.g., a C++ compiler). Such pipelines will benefit from being able to inspect using-declarators, as the transformed source code will more exactly correspond to the class from which it was transformed.

As an aside, the proposed direction ought to make it possible to implement a class_lookup library function that accurately models the algorithm specified in [class.member.lookup], which is pretty sweet. I’m sure we can think of something fun to do with that.

3 Implementation experience

Our proposal for “entity proxies” is entirely implemented in Bloomberg’s Clang/P2996 fork. Passing either -fentity-proxy-reflection or -freflection-latest (the latter being a “catch all” for all implemented reflection and reflection-adjacent papers) enables the feature. An example on Godbolt can be found here.

Splice template arguments are implemented in Clang/P2996, but the effort to refactor and decouple their implementation from “template names” motivated this proposal’s recommendation that they for now be removed.

4 Suggested polls

The authors submit the following polls to EWG for their consideration.

1. Remove support for splice-template-arguments from P2996R12.

SF	F	N	A	SA

2a. Add reflection of “entity proxies” to P2996 and forward to CWG for inclusion in C++26.

SF	F	N	A	SA

2b. Make ^^id ill-formed when id names a using-declaration and forward to CWG for inclusion in C++26.

(Only suggested if [2a] does not find consensus)

SF	F	N	A	SA

5 Proposed wording

5.1 Poll 1: Remove splice-template-arguments from P2996

[ Drafting note: All wording assumes P2996R12. ]

[temp.param] Template parameters

Strike the P2996 changes to the grammar at the beginning of [temp.param]:

[temp.names] Names of template specializations

Strike the P2996 changes to the grammar for template-argument:

[temp.arg.general] General

Strike the sentence from paragraph 1 pertaining to splice template arguments from P2996:

Revert the changes to paragraph 3 from P2996:

[temp.arg.type] Template type arguments

Strike the changes to [temp.arg.type] from P2996:

[temp.arg.template] Template template arguments

Strike the changes to [temp.arg.template] from P2996:

[temp.dep.temp] Dependent template arguments

Strike the paragraph covering splice template arguments from P2996.

5.2 Poll 2a: Augment P2996 with reflection of entity proxies

[basic.pre] Preamble

Add “entity proxies” to the list of entities in pargraph 8.

[basic.lookup] General

Change “named” to “proxied” in paragraph 3.

[class.qual] Class members

Change “names” to “proxies” in paragraph 1.2:

[basic.fundamental] Fundamental types

Add a new bullet to the list of constructs that a reflection can represent.

[expr.reflect] The reflection operator

Extend paragraph 5 to allow a reflect-expression to represent an entity proxy.

[namespace.udecl] The using declaration

Modify paragraph 1 such that a using-declarator introduces an entity called an “entity proxy”.

[module.interface] Export declaration

Adopt the language of “proxying” in paragraph 5.

[class.mem.general] General

Remove using-declarators from the list of declarations that do not introduce a class member in paragraph 4.

[class.copy.assign] Copy/move assignment operator

Use “proxies” in the note that follows paragraph 8.

[class.access.general] General

Refer to the declarations “proxies” by using-declarators, rather than those “named” (i.e., the entity proxies), in paragraph 4.

[over.match.funcs.general] General

Change “nominated” to “proxied” in paragraph 4.

[temp.spec.partial.general] General

Change “refers” to “proxies” in the note that follows paragraph 7.

[meta.reflection.synop]

Add the is_entity_proxy and proxied_entity_of functions.

Change dealias to underlying_entity_of in the second note that follows paragraph 2.

[meta.reflection.operators] Operator representations

Modify operator_of to account for entity proxies:

[meta.reflection.names]

Modify has_identifier to account for entity proxies:

[meta.reflection.queries]

Introduce a metasyntactic function following has-type to “unwrap” a reflection to its underlying entity, while excluding entity proxies.

Disallow entity proxies from being used with value_of.

Specify is_const and is_volatile in terms of DEALIAS.

Also specify is_lvalue_reference_qualified and is_rvalue_reference_qualified in terms of DEALIAS.

Change dealias to DEALIAS for is_complete_type:

Account for entity proxies in the specification of is_enumerable_type.

Use DEALIAS in is_type and is_namespace. Specify the behavior of is_entity_proxy following the specification of is_namespace_alias:

[meta.reflection.member.queries] Reflection member queries

Specify in terms of DEALIAS to disallow entity proxies from several functions. Make entity proxies Q-members-of-representable.

[meta.reflection.layout] Reflection layout queries

Specify in terms of DEALIAS instead of dealias to disallow entity proxies from several functions.

[meta.reflection.define.aggregate] Reflection class definition generation

Specify in terms of DEALIAS instead of dealias to disallow entity proxies from several functions.

5.3 Poll 2b: Make ^^Using::Decl ill-formed for using-declarators

[ Drafting note: All wording assumes P2996R12. ]

[expr.reflect] The reflection operator

Extend paragraph 5 to state that a reflect-expression is ill-formed when it names a using-declarator.

6 References