Document #: | P2996R4 |
Date: | 2024-06-26 |
Project: | Programming Language C++ |
Audience: |
EWG, LEWG |
Reply-to: |
Wyatt Childers <wcc@edg.com> Peter Dimov <pdimov@gmail.com> Dan Katz <dkatz85@bloomberg.net> Barry Revzin <barry.revzin@gmail.com> Andrew Sutton <andrew.n.sutton@gmail.com> Faisal Vali <faisalv@gmail.com> Daveed Vandevoorde <daveed@edg.com> |
make_integer_sequence
hash_append
tuple_cat
^
)
[:
…:]
)
std::meta::info
name_of
,
display_name_of
,
source_location_of
type_of
,
parent_of
,
dealias
object_of
,
value_of
template_of
,
template_arguments_of
members_of
,
static_data_members_of
,
nonstatic_data_members_of
,
bases_of
,
enumerators_of
,
subobjects_of
substitute
reflect_invoke
reflect_value
,
reflect_object
,
reflect_function
extract<T>
test_trait
data_member_spec
,
define_class
typedef
specifierusing enum
declaration<type_traits>
synopsis<meta>
synopsisSince [P2996R3]:
u8name_of
,
u8qualified_name_of
,
u8display_name_of
.reflect_value
:
separated reflect_result
into three
functions: reflect_value
,
reflect_object
,
reflect_function
is_noexcept
to apply to
a wider class of entitiestest_type
and
test_types
to
test_trait
has_module_linkage
metafunctionobject_of
metafunctionSince [P2996R2]:
accessible_members_of
variants to restore a TS-era agreementvalue_of
to
extract
, and expanded it to operate
on functionscan_substitute
,
is_value
,
is_object
, and (new)
value_of
meta::info
yield a null reflectionreflect_invoke
to support template
argumentstype_
to avoid name clashes. added
more generalized is_const
,
is_final
, and
is_volatile
is_noexcept
and fixed
is_explicit
to only apply to member
functions, not member function templatesSince [P2996R1], several changes to the overall library API:
qualified_name_of
(to
partner with name_of
)is_static
for being
ambiguous, added
has_internal_linkage
(and
has_linkage
and
has_external_linkage
) and
is_static_member
insteadis_class_member
,
is_namespace_member
, and
is_concept
reflect_invoke
Other paper changes:
Since [P2996R0]:
synth_struct
to
define_class
entity_ref
and
pointer_to_member
into
value_of
This is a proposal for a reduced initial set of features to support static reflection in C++. Specifically, we are mostly proposing a subset of features suggested in [P1240R2]:
std::meta::info
,^
) that
produces a reflection value for its operand construct,consteval
metafunctions to work with reflections (including deriving
other reflections), and[: refl :]
).(Note that this aims at something a little broader than pure “reflection”. We not only want to observe the structure of the program: We also want to ease generating code that depends on those observations. That combination is sometimes referred to as “reflective metaprogramming”, but within WG21 discussion the term “reflection” has often been used informally to refer to the same general idea.)
This proposal is not intended to be the end-game as far as reflection and compile-time metaprogramming are concerned. Instead, we expect it will be a useful core around which more powerful features will be added incrementally over time. In particular, we believe that most or all the remaining features explored in P1240R2 and that code injection (along the lines described in [P2237R0]) are desirable directions to pursue.
Our choice to start with something smaller is primarily motivated by the belief that that improves the chances of these facilities making it into the language sooner rather than later.
While we tried to select a useful subset of the P1240 features, we
also made a few additions and changes. Most of those changes are minor.
For example, we added a std::meta::test_trait
interface that makes it convenient to use existing standard type
predicates (such as is_class_v
) in
reflection computations.
One addition does stand out, however: We have added metafunctions that permit the synthesis of simple struct and union types. While it is not nearly as powerful as generalized code injection (see [P2237R0]), it can be remarkably effective in practice.
Perhaps the most common suggestion made regarding the framework
outlined in P1240 is to switch from the single std::meta::info
type to a family of types covering various language elements (e.g.,
std::meta::variable
,
std::meta::type
,
etc.).
We believe that doing so would be a mistake with very serious consequences for the future of C++.
Specifically, it would codify the language design into the type
system. We know from experience that it has been quasi-impossible to
change the semantics of standard types once they were standardized, and
there is no reason to think that such evolution would become easier in
the future. Suppose for example that we had standardized a reflection
type std::meta::variable
in C++03 to represent what the standard called “variables” at the time.
In C++11, the term “variable” was extended to include “references”. Such
an change would have been difficult to do given that C++ by then likely
would have had plenty of code that depended on a type arrangement around
the more restricted definition of “variable”. That scenario is clearly
backward-looking, but there is no reason to believe that similar changes
might not be wanted in the future and we strongly believe that it
behooves us to avoid adding undue constraints on the evolution of the
language.
Other advantages of a single opaque type include:
std::vector<std::meta::info>
can easily represent a mixed template argument list — containing types
and nontypes — without fear of slicing values).Lock3 implemented the equivalent of much that is proposed here in a fork of Clang (specifically, it worked with the P1240 proposal, but also included several other capabilities including a first-class injection mechanism).
EDG has an ongoing implementation of this proposal that is currently available on Compiler Explorer (thank you, Matt Godbolt).
Additionally, Bloomberg has open sourced a fork of Clang which provides a second implementation of this proposal, also available on Compiler Explorer (again thank you, Matt Godbolt), which can be found here: https://github.com/bloomberg/clang-p2996.
Neither implementation is complete, but all significant features proposed by this paper have been implemented by at least one implementation (including namespace and template splicers). Both implementations have their “quirks” and continue to evolve alongside this paper.
Nearly all of the examples below have links to Compiler Explorer demonstrating them in both EDG and Clang.
The implementations notably lack some of the other proposed language features that dovetail well with reflection; most notably, expansion statements are absent. A workaround that will be used in the linked implementations of examples is the following facility:
namespace __impl { template<auto... vals> struct replicator_type { template<typename F> constexpr void operator>>(F body) const { (body.template operator()<vals>(), ...); } }; template<auto... vals> <vals...> replicator = {}; replicator_type} template<typename R> consteval auto expand(R range) { ::vector<std::meta::info> args; stdfor (auto r : range) { .push_back(reflect_value(r)); args} return substitute(^__impl::replicator, args); }
Used like:
With expansion statements
|
With expand
workaround
|
---|---|
|
|
We start with a number of examples that show off what is possible with the proposed set of features. It is expected that these are mostly self-explanatory. Read ahead to the next sections for a more systematic description of each element of this proposal.
A number of our examples here show a few other language features that we hope to progress at the same time. This facility does not strictly rely on these features, and it is possible to do without them - but it would greatly help the usability experience if those could be adopted as well:
Our first example is not meant to be compelling but to show how to go back and forth between the reflection domain and the grammatical domain:
constexpr auto r = ^int; typename[:r:] x = 42; // Same as: int x = 42; typename[:^char:] c = '*'; // Same as: char c = '*';
The
typename
prefix can be omitted in the same contexts as with dependent qualified
names (i.e., in what the standard calls type-only contexts).
For example:
using MyType = [:sizeof(int)<sizeof(long)? ^long : ^int:]; // Implicit "typename" prefix.
On Compiler Explorer: EDG, Clang.
Our second example enables selecting a member “by number” for a specific type:
struct S { unsigned i:2, j:6; }; consteval auto member_number(int n) { if (n == 0) return ^S::i; else if (n == 1) return ^S::j; } int main() { {0, 0}; S s.[:member_number(1):] = 42; // Same as: s.j = 42; s.[:member_number(5):] = 0; // Error (member_number(5) is not a constant). s}
This example also illustrates that bit fields are not beyond the reach of this proposal.
On Compiler Explorer: EDG, Clang.
Note that a “member access splice” like s.[:member_number(1):]
is a more direct member access mechanism than the traditional syntax. It
doesn’t involve member name lookup, access checking, or — if the spliced
reflection value denotes a member function — overload resolution.
This proposal includes a number of consteval “metafunctions” that
enable the introspection of various language constructs. Among those
metafunctions is std::meta::nonstatic_data_members_of
which returns a vector of reflection values that describe the non-static
members of a given type. We could thus rewrite the above example as:
struct S { unsigned i:2, j:6; }; consteval auto member_number(int n) { return std::meta::nonstatic_data_members_of(^S)[n]; } int main() { {0, 0}; S s.[:member_number(1):] = 42; // Same as: s.j = 42; s.[:member_number(5):] = 0; // Error (member_number(5) is not a constant). s}
On Compiler Explorer: EDG, Clang.
This proposal specifies that namespace
std::meta
is
associated with the reflection type (std::meta::info
);
the std::meta::
qualification can therefore be omitted in the example above.
Another frequently-useful metafunction is std::meta::name_of
,
which returns a std::string_view
describing the unqualified name of an entity denoted by a given
reflection value. With such a facility, we could conceivably access
non-static data members “by string”:
struct S { unsigned i:2, j:6; }; consteval auto member_named(std::string_view name) { for (std::meta::info field : nonstatic_data_members_of(^S)) { if (name_of(field) == name) return field; } } int main() { {0, 0}; S s.[:member_named("j"):] = 42; // Same as: s.j = 42; s.[:member_named("x"):] = 0; // Error (member_named("x") is not a constant). s}
On Compiler Explorer: EDG, Clang.
Here, sizes
will be a std::array<std::size_t, 3>
initialized with {sizeof(int), sizeof(float), sizeof(double)}
:
constexpr std::array types = {^int, ^float, ^double}; constexpr std::array sizes = []{ ::array<std::size_t, types.size()> r; std::views::transform(types, r.begin(), std::meta::size_of); stdreturn r; }();
Compare this to the following type-based approach, which produces the
same array sizes
:
template<class...> struct list {}; using types = list<int, float, double>; constexpr auto sizes = []<template<class...> class L, class... T>(L<T...>) { return std::array<std::size_t, sizeof...(T)>{{ sizeof(T)... }}; }(types{});
On Compiler Explorer: EDG, Clang.
make_integer_sequence
We can provide a better implementation of
make_integer_sequence
than a
hand-rolled approach using regular template metaprogramming (although
standard libraries today rely on an intrinsic for this):
#include <utility> #include <vector> template<typename T> consteval std::meta::info make_integer_seq_refl(T N) { ::vector args{^T}; stdfor (T k = 0; k < N; ++k) { .push_back(std::meta::reflect_value(k)); args} return substitute(^std::integer_sequence, args); } template<typename T, T N> using make_integer_sequence = [:make_integer_seq_refl<T>(N):];
On Compiler Explorer: EDG, Clang.
Note that the memoization implicit in the template substitution
process still applies. So having multiple uses of, e.g., make_integer_sequence<int, 20>
will only involve one evaluation of make_integer_seq_refl<int>(20)
.
struct member_descriptor { ::size_t offset; std::size_t size; std}; // returns std::array<member_descriptor, N> template <typename S> consteval auto get_layout() { constexpr auto members = nonstatic_data_members_of(^S); ::array<member_descriptor, members.size()> layout; stdfor (int i = 0; i < members.size(); ++i) { [i] = {.offset=offset_of(members[i]), .size=size_of(members[i])}; layout} return layout; } struct X { char a; int b; double c; }; /*constexpr*/ auto Xd = get_layout<X>(); /* where Xd would be std::array<member_descriptor, 3>{{ { 0, 1 }, { 4, 4 }, { 8, 8 } }} */
On Compiler Explorer: EDG, Clang.
One of the most commonly requested facilities is to convert an enum value to a string (this example relies on expansion statements):
template <typename E> requires std::is_enum_v<E> constexpr std::string enum_to_string(E value) { template for (constexpr auto e : std::meta::enumerators_of(^E)) { if (value == [:e:]) { return std::string(std::meta::name_of(e)); } } return "<unnamed>"; } enum Color { red, green, blue }; static_assert(enum_to_string(Color::red) == "red"); static_assert(enum_to_string(Color(42)) == "<unnamed>");
We can also do the reverse in pretty much the same way:
template <typename E> requires std::is_enum_v<E> constexpr std::optional<E> string_to_enum(std::string_view name) { template for (constexpr auto e : std::meta::enumerators_of(^E)) { if (name == std::meta::name_of(e)) { return [:e:]; } } return std::nullopt; }
But we don’t have to use expansion statements - we can also use
algorithms. For instance,
enum_to_string
can also be
implemented this way (this example relies on non-transient constexpr
allocation), which also demonstrates choosing a different algorithm
based on the number of enumerators:
template <typename E> requires std::is_enum_v<E> constexpr std::string enum_to_string(E value) { constexpr auto get_pairs = []{ return std::meta::enumerators_of(^E) | std::views::transform([](std::meta::info e){ return std::pair<E, std::string>(std::meta::extract<E>(e), std::meta::name_of(e)); }) }; constexpr auto get_name = [](E value) -> std::optional<std::string> { if constexpr (enumerators_of(^E).size() <= 7) { // if there aren't many enumerators, use a vector with find_if() constexpr auto enumerators = get_pairs() | std::ranges::to<std::vector>(); auto it = std::ranges::find_if(enumerators, [value](auto const& pr){ return pr.first == value; }; if (it == enumerators.end()) { return std::nullopt; } else { return it->second; } } else { // if there are lots of enumerators, use a map with find() constexpr auto enumerators = get_pairs() | std::ranges::to<std::map>(); auto it = enumerators.find(value); if (it == enumerators.end()) { return std::nullopt; } else { return it->second; } } }; return get_name(value).value_or("<unnamed>"); }
Note that this last version has lower complexity: While the versions
using an expansion statement use an expected O(N) number of comparisons
to find the matching entry, a
std::map
achieves the same with O(log(N)) complexity (where N is the number of
enumerator constants).
On Compiler Explorer: EDG, Clang.
Many many variations of these functions are possible and beneficial depending on the needs of the client code. For example:
enumerators_of(^E)
enum_to_string
and
string_to_enum
with a minimal
footprintOur next example shows how a command-line option parser could work by automatically inferring flags based on member names. A real command-line parser would of course be more complex, this is just the beginning.
template<typename Opts> auto parse_options(std::span<std::string_view const> args) -> Opts { Opts opts;template for (constexpr auto dm : nonstatic_data_members_of(^Opts)) { auto it = std::ranges::find_if(args, [](std::string_view arg){ return arg.starts_with("--") && arg.substr(2) == name_of(dm); }); if (it == args.end()) { // no option provided, use default continue; } else if (it + 1 == args.end()) { ::print(stderr, "Option {} is missing a value\n", *it); std::exit(EXIT_FAILURE); std} using T = typename[:type_of(dm):]; auto iss = std::ispanstream(it[1]); if (iss >> opts.[:dm:]; !iss) { ::print(stderr, "Failed to parse option {} into a {}\n", *it, display_name_of(^T)); std::exit(EXIT_FAILURE); std} } return opts; } struct MyOpts { ::string file_name = "input.txt"; // Option "--file_name <string>" stdint count = 1; // Option "--count <int>" }; int main(int argc, char *argv[]) { = parse_options<MyOpts>(std::vector<std::string_view>(argv+1, argv+argc)); MyOpts opts // ... }
This example is based on a presentation by Matúš Chochlík.
On Compiler Explorer: EDG, Clang.
#include <meta> template<typename... Ts> struct Tuple { struct storage; static_assert(is_type(define_class(^storage, {data_member_spec(^Ts)...}))); storage data; (): data{} {} Tuple(Ts const& ...vs): data{ vs... } {} Tuple}; template<typename... Ts> struct std::tuple_size<Tuple<Ts...>>: public integral_constant<size_t, sizeof...(Ts)> {}; template<std::size_t I, typename... Ts> struct std::tuple_element<I, Tuple<Ts...>> { static constexpr std::array types = {^Ts...}; using type = [: types[I] :]; }; consteval std::meta::info get_nth_field(std::meta::info r, std::size_t n) { return nonstatic_data_members_of(r)[n]; } template<std::size_t I, typename... Ts> constexpr auto get(Tuple<Ts...> &t) noexcept -> std::tuple_element_t<I, Tuple<Ts...>>& { return t.data.[:get_nth_field(^decltype(t.data), I):]; } // Similarly for other value categories...
This example uses a “magic” std::meta::define_class
template along with member reflection through the
nonstatic_data_members_of
metafunction to implement a
std::tuple
-like
type without the usual complex and costly template metaprogramming
tricks that that involves when these facilities are not available.
define_class
takes a reflection for
an incomplete class or union plus a vector of non-static data member
descriptions, and completes the give class or union type to have the
described members.
On Compiler Explorer: EDG, Clang.
Similarly to how we can implement a tuple using
define_class
to create on the fly a
type with one member for each
Ts...
, we
can implement a variant that simply defines a
union
instead of a
struct
. One
difference here is how the destructor of a
union
is
currently defined:
union U1 { int i; char c; }; union U2 { int i; ::string s; std};
U1
has a trivial destructor, but
U2
’s destructor is defined as
deleted (because
std::string
has a non-trivial destructor). This is a problem because we need to
define this thing… somehow. However, for the purposes of
define_class
, there really is only
one reasonable option to choose here:
template <class... Ts> union U { // all of our members ... members; Ts // a defaulted destructor if all of the types are trivially destructible constexpr ~U() requires (std::is_trivially_destructible_v<Ts> && ...) = default; // ... otherwise a destructor that does nothing constexpr ~U() { } };
If we make define_class
for a union
have this behavior, then we can implement a
variant
in a much more
straightforward way than in current implementations. This is not a
complete implementation of
std::variant
(and cheats using libstdc++ internals, and also uses Boost.Mp11’s
mp_with_index
) but should
demonstrate the idea:
template <typename... Ts> class Variant { union Storage; struct Empty { }; static_assert(is_type(define_class(^Storage, { (^Empty, {.name="empty"}), data_member_spec(^Ts)... data_member_spec}))); static consteval std::meta::info get_nth_field(std::size_t n) { return nonstatic_data_members_of(^Storage)[n+1]; } Storage storage_;int index_ = -1; // cheat: use libstdc++'s implementation template <typename T> static constexpr size_t accepted_index = std::__detail::__variant::__accepted_index<T, std::variant<Ts...>>; template <class F> constexpr auto with_index(F&& f) const -> decltype(auto) { return mp_with_index<sizeof...(Ts)>(index_, (F&&)f); } public: constexpr Variant() requires std::is_default_constructible_v<Ts...[0]> // should this work: storage_{. [: get_nth_field(0) :]{} } : storage_{.empty={}} (0) , index_{ ::construct_at(&storage_.[: get_nth_field(0) :]); std} constexpr ~Variant() requires (std::is_trivially_destructible_v<Ts> and ...) = default; constexpr ~Variant() { if (index_ != -1) { ([&](auto I){ with_index::destroy_at(&storage_.[: get_nth_field(I) :]); std}); } } template <typename T, size_t I = accepted_index<T&&>> requires (!std::is_base_of_v<Variant, std::decay_t<T>>) constexpr Variant(T&& t) : storage_{.empty={}} (-1) , index_{ ::construct_at(&storage_.[: get_nth_field(I) :], (T&&)t); std= (int)I; index_ } // you can't actually express this constraint nicely until P2963 constexpr Variant(Variant const&) requires (std::is_trivially_copyable_v<Ts> and ...) = default; constexpr Variant(Variant const& rhs) requires ((std::is_copy_constructible_v<Ts> and ...) and not (std::is_trivially_copyable_v<Ts> and ...)) : storage_{.empty={}} (-1) , index_{ .with_index([&](auto I){ rhsconstexpr auto field = get_nth_field(I); ::construct_at(&storage_.[: field :], rhs.storage_.[: field :]); std= I; index_ }); } constexpr auto index() const -> int { return index_; } template <class F> constexpr auto visit(F&& f) const -> decltype(auto) { if (index_ == -1) { throw std::bad_variant_access(); } return mp_with_index<sizeof...(Ts)>(index_, [&](auto I) -> decltype(auto) { return std::invoke((F&&)f, storage_.[: get_nth_field(I) :]); }); } };
Effectively, Variant<T, U>
synthesizes a union type Storage
which looks like this:
union Storage { Empty empty; T unnamed0; U unnamed1; ~Storage() requires std::is_trivially_destructible_v<T> && std::is_trivially_destructible_v<U> = default; ~Storage() { } }
The question here is whether we should be should be able to directly initialize members of a defined union using a splicer, as in:
: storage{.[: get_nth_field(0) :]={}}
Arguably, the answer should be yes - this would be consistent with how other accesses work. This is instead proposed in [P3293R0].
On Compiler Explorer: EDG, Clang.
#include <meta> #include <array> template <typename T, std::size_t N> struct struct_of_arrays_impl; consteval auto make_struct_of_arrays(std::meta::info type, ::meta::info N) -> std::meta::info { std::vector<std::meta::info> old_members = nonstatic_data_members_of(type); std::vector<std::meta::info> new_members = {}; stdfor (std::meta::info member : old_members) { auto type_array = substitute(^std::array, {type_of(member), N }); auto mem_descr = data_member_spec(type_array, {.name = name_of(member)}); .push_back(mem_descr); new_members} return std::meta::define_class( (^struct_of_arrays_impl, {type, N}), substitute); new_members} template <typename T, size_t N> using struct_of_arrays = [: make_struct_of_arrays(^T, ^N) :];
Example:
struct point { float x; float y; float z; }; using points = struct_of_arrays<point, 30>; // equivalent to: // struct points { // std::array<float, 30> x; // std::array<float, 30> y; // std::array<float, 30> z; // };
Again, the combination of
nonstatic_data_members_of
and
define_class
is put to good use.
On Compiler Explorer: EDG, Clang.
Now that we’ve seen a couple examples of using std::meta::define_class
to create a type, we can create a more sophisticated command-line parser
example.
This is the opening example for clap (Rust’s Command Line Argument Parser):
struct Args : Clap { <std::string, {.use_short=true, .use_long=true}> name; Option<int, {.use_short=true, .use_long=true}> count = 1; Option}; int main(int argc, char** argv) { auto opts = Args{}.parse(argc, argv); for (int i = 0; i < opts.count; ++i) { // opts.count has type int ::print("Hello {}!", opts.name); // opts.name has type std::string std} }
Which we can implement like this:
struct Flags { bool use_short; bool use_long; }; template <typename T, Flags flags> struct Option { ::optional<T> initializer = {}; std // some suitable constructors and accessors for flags }; // convert a type (all of whose non-static data members are specializations of Option) // to a type that is just the appropriate members. // For example, if type is a reflection of the Args presented above, then this // function would evaluate to a reflection of the type // struct { // std::string name; // int count; // } consteval auto spec_to_opts(std::meta::info opts, ::meta::info spec) -> std::meta::info { std::vector<std::meta::info> new_members; stdfor (std::meta::info member : nonstatic_data_members_of(spec)) { auto type_new = template_arguments_of(type_of(member))[0]; .push_back(data_member_spec(type_new, {.name=name_of(member)})); new_members} return define_class(opts, new_members); } struct Clap { template <typename Spec> auto parse(this Spec const& spec, int argc, char** argv) { ::vector<std::string_view> cmdline(argv+1, argv+argc) std // check if cmdline contains --help, etc. struct Opts; static_assert(is_type(spec_to_opts(^Opts, ^Spec))); Opts opts; template for (constexpr auto [sm, om] : std::views::zip(nonstatic_data_members_of(^Spec), (^Opts))) { nonstatic_data_members_ofauto const& cur = spec.[:sm:]; constexpr auto type = type_of(om); // find the argument associated with this option auto it = std::ranges::find_if(cmdline, [&](std::string_view arg){ return (cur.use_short && arg.size() == 2 && arg[0] == '-' && arg[1] == name_of(sm)[0]) || (cur.use_long && arg.starts_with("--") && arg.substr(2) == name_of(sm)); }); // no such argument if (it == cmdline.end()) { if constexpr (has_template_arguments(type) and template_of(type) == ^std::optional) { // the type is optional, so the argument is too continue; } else if (cur.initializer) { // the type isn't optional, but an initializer is provided, use that .[:om:] = *cur.initializer; optscontinue; } else { ::print(stderr, "Missing required option {}\n", name_of(sm)); std::exit(EXIT_FAILURE); std} } else if (it + 1 == cmdline.end()) { ::print(stderr, "Option {} for {} is missing a value\n", *it, name_of(sm)); std::exit(EXIT_FAILURE); std} // found our argument, try to parse it auto iss = ispanstream(it[1]); if (iss >> opts.[:om:]; !iss) { ::print(stderr, "Failed to parse {:?} into option {} of type {}\n", std[1], name_of(sm), display_name_of(type)); it::exit(EXIT_FAILURE); std} } return opts; } };
On Compiler Explorer: EDG, Clang.
This example is taken from Boost.Describe:
struct universal_formatter { constexpr auto parse(auto& ctx) { return ctx.begin(); } template <typename T> auto format(T const& t, auto& ctx) const { auto out = std::format_to(ctx.out(), "{}{{", name_of(^T)); auto delim = [first=true]() mutable { if (!first) { *out++ = ','; *out++ = ' '; } = false; first }; template for (constexpr auto base : bases_of(^T)) { (); delim= std::format_to(out, "{}", (typename [: type_of(base) :] const&)(t)); out } template for (constexpr auto mem : nonstatic_data_members_of(^T)) { (); delim= std::format_to(out, ".{}={}", name_of(mem), t.[:mem:]); out } *out++ = '}'; return out; } }; struct B { int m0 = 0; }; struct X { int m1 = 1; }; struct Y { int m2 = 2; }; class Z : public X, private Y { int m3 = 3; int m4 = 4; }; template <> struct std::formatter<B> : universal_formatter { }; template <> struct std::formatter<X> : universal_formatter { }; template <> struct std::formatter<Y> : universal_formatter { }; template <> struct std::formatter<Z> : universal_formatter { }; int main() { ::println("{}", Z()); std// Z{X{B{.m0=0}, .m1 = 1}, Y{{.m0=0}, .m2 = 2}, .m3 = 3, .m4 = 4} }
On Compiler Explorer: Clang.
Note that currently, we do not have the ability to access a base
class subobject using the t.[: base :]
syntax - which means that the only way to get at the base is to use a
cast:
static_cast<[: type_of(base) const& :]>(t)
,
or(typename [: type_of(base) :] const&)t
Both have to explicitly specify the
const
-ness
of the type in the cast. The
static_cast
additionally has to check access. The C-style cast is one many people
find unsavory, though in this case it avoids checking access - but
requires writing
typename
since this isn’t a type-only context.
hash_append
Based on the [N3980] API:
template <typename H, typename T> requires std::is_standard_layout_v<T> void hash_append(H& algo, T const& t) { template for (constexpr auto mem : nonstatic_data_members_of(^T)) { (algo, t.[:mem:]); hash_append} }
This approach requires allowing packs in structured bindings [P1061R5], but can also be written using
std::make_index_sequence
:
template <typename T> constexpr auto struct_to_tuple(T const& t) { constexpr auto members = nonstatic_data_members_of(^T); constexpr auto indices = []{ ::array<int, members.size()> indices; std::ranges::iota(indices, 0); stdreturn indices; }(); constexpr auto [...Is] = indices; return std::make_tuple(t.[: members[Is] :]...); }
An alternative approach is:
consteval auto type_struct_to_tuple(info type) -> info { return substitute(^std::tuple, (type) nonstatic_data_members_of| std::views::transform(std::meta::type_of) | std::views::transform(std::meta::type_remove_cvref) | std::ranges::to<std::vector>()); } template <typename To, typename From, std::meta::info ... members> constexpr auto struct_to_tuple_helper(From const& from) -> To { return To(from.[:members:]...); } template<typename From> consteval auto get_struct_to_tuple_helper() { using To = [: type_struct_to_tuple(^From): ]; ::vector args = {^To, ^From}; stdfor (auto mem : nonstatic_data_members_of(^From)) { .push_back(reflect_value(mem)); args} /* Alternatively, with Ranges: args.append_range( nonstatic_data_members_of(^From) | std::views::transform(std::meta::reflect_value) ); */ return extract<To(*)(From const&)>( (^struct_to_tuple_helper, args)); substitute} template <typename From> constexpr auto struct_to_tuple(From const& from) { return get_struct_to_tuple_helper<From>()(from); }
Here, type_struct_to_tuple
takes
a reflection of a type like struct { T t; U const& u; V v; }
and returns a reflection of the type std::tuple<T, U, V>
.
That gives us the return type. Then,
struct_to_tuple_helper
is a function
template that does the actual conversion — which it can do by having all
the reflections of the members as a non-type template parameter pack.
This is a
constexpr
function and not a
consteval
function because in the general case the conversion is a run-time
operation. However, determining the instance of
struct_to_tuple_helper
that is
needed is a compile-time operation and has to be performed with a
consteval
function (because the function invokes
nonstatic_data_members_of
), hence
the separate function template get_struct_to_tuple_helper()
.
Everything is put together by using
substitute
to create the
instantiation of
struct_to_tuple_helper
that we need,
and a compile-time reference to that instance is obtained with
extract
. Thus
f
is a function reference to the
correct specialization of
struct_to_tuple_helper
, which we can
simply invoke.
On Compiler Explorer (with a different implementation than either of the above): EDG, Clang.
tuple_cat
Courtesy of Tomasz Kaminski, on compiler explorer:
template<std::pair<std::size_t, std::size_t>... indices> struct Indexer { template<typename Tuples> // Can use tuple indexing instead of tuple of tuples auto operator()(Tuples&& tuples) const { using ResultType = std::tuple< ::tuple_element_t< std.second, indices::remove_cvref_t<std::tuple_element_t<indices.first, std::remove_cvref_t<Tuples>>> std>... >; return ResultType(std::get<indices.second>(std::get<indices.first>(std::forward<Tuples>(tuples)))...); } }; template <class T> consteval auto subst_by_value(std::meta::info tmpl, std::vector<T> args) -> std::meta::info { ::vector<std::meta::info> a2; stdfor (T x : args) { .push_back(std::meta::reflect_value(x)); a2} return substitute(tmpl, a2); } consteval auto make_indexer(std::vector<std::size_t> sizes) -> std::meta::info { ::vector<std::pair<int, int>> args; std for (std::size_t tidx = 0; tidx < sizes.size(); ++tidx) { for (std::size_t eidx = 0; eidx < sizes[tidx]; ++eidx) { .push_back({tidx, eidx}); args} } return subst_by_value(^Indexer, args); } template<typename... Tuples> auto my_tuple_cat(Tuples&&... tuples) { constexpr typename [: make_indexer({type_tuple_size(type_remove_cvref(^Tuples))...}) :] indexer; return indexer(std::forward_as_tuple(std::forward<Tuples>(tuples)...)); }
The tricky thing with implementing a named tuple is actually strings
as non-type template parameters. Because you cannot just pass "x"
into
a non-type template parameter of the form
auto V
, that
leaves us with two ways of specifying the constituents:
pair
type so
that we can write make_named_tuple<pair<int, "x">, pair<double, "y">>()
,
or<^int, std::meta::reflect_value("x"),
make_named_tuple^double, std::meta::reflect_value("y")>()
We do not currently support splicing string literals, and the
pair
approach follows the similar
pattern already shown with
define_class
(given a suitable
fixed_string
type):
template <class T, fixed_string Name> struct pair { static constexpr auto name() -> std::string_view { return Name.view(); } using type = T; }; template <class... Tags> consteval auto make_named_tuple(std::meta::info type, Tags... tags) { ::vector<std::meta::info> nsdms; stdauto f = [&]<class Tag>(Tag tag){ .push_back(data_member_spec( nsdms(^typename Tag::type), dealias{.name=Tag::name()})); }; (f(tags), ...); return define_class(type, nsdms); } struct R; static_assert(is_type(make_named_tuple(^R, pair<int, "x">{}, pair<double, "y">{}))); static_assert(type_of(nonstatic_data_members_of(^R)[0]) == ^int); static_assert(type_of(nonstatic_data_members_of(^R)[1]) == ^double); int main() { [[maybe_unused]] auto r = R{.x=1, .y=2.0}; }
On Compiler Explorer: EDG, Clang.
Alternatively, can side-step the question of non-type template parameters entirely by keeping everything in the value domain:
consteval auto make_named_tuple(std::meta::info type, ::initializer_list<std::pair<std::meta::info, std::string_view>> members) { std::vector<std::meta::data_member_spec> nsdms; stdfor (auto [type, name] : members) { .push_back(data_member_spec(type, {.name=name})); nsdms} return define_class(type, nsdms); } struct R; static_assert(is_type(make_named_tuple(^R, {{^int, "x"}, {^double, "y"}}))); static_assert(type_of(nonstatic_data_members_of(^R)[0]) == ^int); static_assert(type_of(nonstatic_data_members_of(^R)[1]) == ^double); int main() { [[maybe_unused]] auto r = R{.x=1, .y=2.0}; }
On Compiler Explorer: EDG
and Clang (the EDG and Clang implementations differ only in Clang
having the updated data_member_spec
API that returns an info
).
The features proposed here make it a little easier to update a ticket
counter at compile time. This is not an ideal implementation (we’d
prefer direct support for compile-time —– i.e.,
consteval
—
variables), but it shows how compile-time mutable state surfaces in new
ways.
class TU_Ticket { template<int N> struct Helper; public: static consteval int next() { int k = 0; // Search for the next incomplete 'Helper<k>'. ::meta::info r; stdwhile (!is_incomplete_type(r = substitute(^Helper, { std::meta::reflect_value(k) }))) ++k; // Define 'Helper<k>' and return its index. (r, {}); define_classreturn k; } }; constexpr int x = TU_Ticket::next(); static_assert(x == 0); constexpr int y = TU_Ticket::next(); static_assert(y == 1); constexpr int z = TU_Ticket::next(); static_assert(z == 2);
On Compiler Explorer: EDG, Clang.
Although we believe a single opaque std::meta::info
type to be the best and most scalable foundation for reflection, we
acknowledge the desire expressed by SG7 for future support for “typeful
reflection”. The following demonstrates one possible means of assembling
a typeful reflection library, in which different classes of reflections
are represented by distinct types, on top of the facilities proposed
here.
// Represents a 'std::meta::info' constrained by a predicate. template <std::meta::info Pred> requires (test_trait(^std::predicate, {type_of(Pred), ^std::meta::info})) struct metatype { ::meta::info value; std // Construction is ill-formed unless predicate is satisfied. consteval metatype(std::meta::info r) : value(r) { if (![:Pred:](r)) throw "Reflection is not a member of this metatype"; } // Cast to 'std::meta::info' allows values of this type to be spliced. consteval operator std::meta::info() const { return value; } static consteval bool check(std::meta::info r) { return [:Pred:](r); } }; // Type representing a "failure to match" any known metatypes. struct unmatched { consteval unmatched(std::meta::info) {} static consteval bool check(std::meta::info) { return true; } }; // Returns the given reflection "enriched" with a more descriptive type. template <typename... Choices> consteval std::meta::info enrich(std::meta::info r) { // Because we control the type, we know that the constructor taking info is // the first constructor. The copy/move constructors are added at the }, so // will be the last ones in the list. ::array ctors = {members_of(^Choices, std::meta::is_constructor)[0]..., std(^unmatched, std::meta::is_constructor)[0]}; members_of::array checks = {^Choices::check..., ^unmatched::check}; std for (auto [check, ctor] : std::views::zip(checks, ctors)) if (extract<bool>(reflect_invoke(check, {reflect_value(r)}))) return reflect_invoke(ctor, {reflect_value(r)}); ::unreachable(); std}
We can leverage this machinery to select different function overloads based on the “type” of reflection provided as an argument.
using type_t = metatype<^std::meta::is_type>; using template_t = metatype<^std::meta::is_template>; // Example of a function overloaded for different "types" of reflections. void PrintKind(type_t) { std::println("type"); } void PrintKind(template_t) { std::println("template"); } void PrintKind(unmatched) { std::println("unknown kind"); } int main() { // Classifies any reflection as one of: Type, Function, or Unmatched. auto enrich = [](std::meta::info r) { return ::enrich<type_t, >(r); }; template_t // Demonstration of using 'enrich' to select an overload. ([:enrich(^metatype):]); // "template" PrintKind([:enrich(^type_t):]); // "type" PrintKind([:enrich(std::meta::reflect_value(3):]); // "unknown kind" PrintKind}
Note that the metatype
class can
be generalized to wrap values of any literal type, or to wrap multiple
values of possibly different types. This has been used, for instance, to
select compile-time overloads based on: whether two integers share the
same parity, the presence or absence of a value in an
optional
, the type of the value held
by a variant
or an
any
, or the syntactic form of a
compile-time string.
Achieving the same in C++23, with the same generality, would require spelling the argument(s) twice: first to obtain a “classification tag” to use as a template argument, and again to call the function, i.e.,
::PrintKind<classify(^int)>(^int). Printer// or worse... <classify(Arg1, Arg2, Arg3)>(Arg1, Arg2, Arg3). fn
On Compiler Explorer: Clang.
^
)The reflection operator produces a reflection value from a grammatical construct (its operand):
unary-expression:
…
^
::
^
namespace-name
^
type-id
^
id-expression
The expression
^::
evaluates to a reflection of the global namespace. When the operand is a
namespace-name or type-id, the resulting value is a
reflection of the designated namespace or type.
When the operand is an id-expression, the resulting value is a reflection of the designated entity found by lookup. This might be any of:
For all other operands, the expression is ill-formed. In a SFINAE context, a failure to substitute the operand of a reflection operator construct causes that construct to not evaluate to constant.
Earlier revisions of this paper allowed for taking the reflection of
any cast-expression that could be evaluated as a constant
expression, as we believed that a constant expression could be
internally “represented” by just capturing the value to which it
evaluated. However, the possibility of side effects from constant
evaluation (introduced by this very paper) renders this approach
infeasible: even a constant expression would have to be evaluated every
time it’s spliced. It was ultimately decided to defer all support for
expression reflection, but we intend to introduce it through a future
paper using the syntax ^(expr)
.
This paper does, however, support reflections of values and of objects (including subobjects). Such reflections arise naturally when iterating over template arguments.
template <int P1, const int &P2> void fn() {}
static constexpr int p[2] = {1, 2};
constexpr auto spec = ^fn<p[0], p[1]>;
static_assert(is_value(template_arguments_of(spec)[0]));
static_assert(is_object(template_arguments_of(spec)[1]));
static_assert(!is_variable(template_arguments_of(spec)[1]));
static_assert([:template_arguments_of(spec)[0]:] == 1);
static_assert(&[:template_arguments_of(spec)[1]:] == &p[1]);
Such reflections cannot generally be obtained using the
^
-operator,
but the std::meta::reflect_value
and std::meta::reflect_object
functions make it easy to reflect particular values or objects. The
std::meta::value_of
metafunction can also be used to map a reflection of an object to a
reflection of its value.
The original TS landed on reflexpr(...)
as the syntax to reflect source constructs and [P1240R0] adopted that syntax as well. As
more examples were discussed, it became clear that that syntax was both
(a) too “heavy” and (b) insufficiently distinct from a function call.
SG7 eventually agreed upon the prefix
^
operator.
The “upward arrow” interpretation of the caret matches the “lift” or
“raise” verbs that are sometimes used to describe the reflection
operation in other contexts.
The caret already has a meaning as a binary operator in C++
(“exclusive OR”), but that is clearly not conflicting with a prefix
operator. In C++/CLI (a Microsoft C++ dialect) the caret is also used as
a new kind of ptr-operator
(9.3.1 [dcl.decl.general])
to declare “handles”.
That is also not conflicting with the use of the caret as a unary
operator because C++/CLI uses the usual prefix
*
operator
to dereference handles.
Apple also uses the caret in syntax “blocks” and unfortunately we believe that does conflict with our proposed use of the caret.
Since the syntax discussions in SG7 landed on the use of the caret,
new basic source characters have become available:
@
,
`
, and
$
. While we have since discussed
some alternatives (e.g.,
@
for
lifting, \
and
/
for
“raising” and “lowering”), we have grown quite fond of the existing
syntax.
[:
…:]
)A reflection can be “spliced” into source code using one of several splicer forms:
[: r :]
produces an expression evaluating to the entity represented by
r
in grammatical contexts that
permit expressions. In type-only contexts (13.8.1 [temp.res.general]/4),
[: r :]
produces a type (and r
must be the
reflection of a type). In contexts that only permit a namespace name,
[: r :]
produces a namespace (and r
must be
the reflection of a namespace or alias thereof).typename[: r :]
produces a simple-type-specifier corresponding to the type
represented by r
.template[: r :]
produces a template-name corresponding to the template
represented by r
.[:r:]::
produces a nested-name-specifier corresponding to the
namespace, enumeration type, or class type represented by
r
.The operand of a splicer is implicitly converted to a std::meta::info
prvalue (i.e., if the operand expression has a class type that with a
conversion function to convert to std::meta::info
,
splicing can still work).
Attempting to splice a reflection value that does not meet the requirement of the splice is ill-formed. For example:
typename[: ^:: :] x = 0; // Error.
In the same way that &C::mem
can produce a pointer, pointer to member data, pointer to function, or
pointer to member function depending on what
mem
refers to, &[: r :]
can likewise produce the same set of pointers if
r
is a reflection of a suitable
entity:
r
is a reflection of a static
data member or a variable, &[:r:]
is a pointer.r
is a reflection
of a non-static data member, &[:r:]
is a pointer to data member.r
is a reflection
of a static member function, a function, or a non-static member function
with an explicit object parameter, &[:r:]
is a pointer to functionr
is a reflection
of a non-static member function with an implicit object parameter, &[:r:]
is a pointer to member function.r
is a reflection
of a function template or member function template, &[:r:]
is the address of that overload set - which would then require external
context to resolve as usual.For most members, this doesn’t even require any additional wording since that’s just what you get when you take the address of the splice based on the current rules we have today.
Now, there are a couple interesting cases to point out when &[:r:]
isn’t just the same as &X::f
.
When r
is a reflection of a
function or function template that is part of an overload set, overload
resolution will not consider the whole overload set, just the specific
function or function template that r
reflects:
struct C { template <class T> void f(T); // #1 void f(int); // #2 }; void (C::*p1)(int) = &C::f; // error: ambiguous constexpr auto f1 = members_of(^C, /* function templates named f */)[0]; constexpr auto f2 = members_of(^C, /* functions named f */)[0]; void (C::*p2)(int) = &[:f1:]; // ok, refers to C::f<int> (#1) void (C::*p3)(int) = &[:f2:]; // ok, refers to C::f (#2)
Another interesting question is what does this mean when
r
is the reflection of a constructor
or destructor? Consider the type:
struct X { (int, int); X};
And let rc
be a reflection of the
constructor and rd
be a reflection
of the destructor. The sensible syntax and semantics for how you would
use rc
and
rd
should be as follows:
auto x = [: rc :](1, 2); // gives you an X .[: rd :](); // destroys it x
Or, with pointers:
auto pc = &[: rc :]; auto pd = &[: rd :]; auto x = (*pc)(1, 2); // gives you an X (x.*pd)(); // destroys it
That is, splicing a constructor behaves like a free function that
produces an object of that type, so &[: rc :]
has type X(*)(int, int)
.
On the other hand, splicing a destructor behaves like a regular member
function, so &[: rd :]
has type void (X::*)()
.
However, we are not proposing splicing constructors or destructors at the moment.
Splicers can appear in many contexts, but our implementation experience has uncovered a small set of circumstances in which a splicer must be disallowed. Mostly these are because any entity designated by a splicer can be dependent on a template argument, so any context in which the language already disallows a dependent name must also disallow a dependent splicer. It also becomes possible for the first time to have the “name” of a namespace or concept become dependent on a template argument. Our implementation experience has helped to sort through which uses of these dependent names pose no difficulties, and which must be disallowed.
This proposal places the following limitations on splicers.
Iterating over the members of a class (e.g., using std::meta::members_of
)
allows one, for the first time, to obtain “handles” representing
constructors. An immediate question arises of whether it’s possible to
reify these constructors to construct objects, or even to take their
address. While we are very interested in exploring these ideas, we defer
their discussion to a future paper; this proposal disallows splicing a
reflection of a constructor (or constructor template) in any
context.
namespace A {}
constexpr std::meta::info NS_A = ^A;
namespace B {
namespace [:NS_A:] {
void fn(); // Is this '::A::fn' or '::B::A::fn' ?
}
}
We found no satisfying answer as to how to interpret examples like the one given above. Neither did we find motivating use cases: many of the “interesting” uses for reflections of namespaces are either to introspect their members, or to pass them as template arguments - but the above example does nothing to help with introspection, and neither can namespaces be reopened within any dependent context. Rather than choose between unintuitive options for a syntax without a motivating use case, we are disallowing splicers from appearing in the opening of a namespace.
template <std::meta::info R> void fn1() {
using enum [:R:]::EnumCls; // #1
// ...
}
template <std::meta::info R> void fn2() {
using namespace [:R:]; // #2
// ...
}
C++20 already disallowed dependent enumeration types from appearing in using-enum-declarators (as in #1), as it would otherwise force the parser to consider every subsequent identifier as possibly a member of the substituted enumeration type. We extend this limitation to splices of dependent reflections of enumeration types, and further disallow the use of dependent reflections of namespaces in using-directives (as in #2) following the same principle.
template <typename T> concept C = requires { requires true; };
template <std::meta::info R> struct Outer {
template <template [:R:] S> struct Inner { /* ... */ };
};
What kind of parameter is S
? If
R
reflects a class template, then it
is a non-type template parameter of deduced type, but if
R
reflects a concept, it is a type
template parameter. There is no other circumstance in the language for
which it is not possible to decide at parse time whether a template
parameter is a type or a non-type, and we don’t wish to introduce one
for this use case.
The most obvious solution would be to introduce a concept [:R:]
syntax that requires that R
reflect
a concept, and while this could be added going forward, we weren’t
convinced of its value at this time - especially since the above can
easily be rewritten:
template <std::meta::info R> struct Outer {
template <typename T> requires template [:R:]<T> { /* ... */ };
};
We are resolving this ambiguity by simply disallowing a reflection of
a concept, whether dependent or otherwise, from being spliced in the
declaration of a template parameter (thus in the above example, the
parser can assume that S
is a
non-type parameter).
struct S { int a; };
constexpr S s = {.[:^S::a:] = 2};
Although we would like for splices of class members to be usable as designators in an initializer-list, we lack implementation experience with the syntax and would first like to verify that there are no issues with dependent reflections. We are very likely to propose this as an extension in a future paper.
The splicers described above all take a single object of type std::meta::info
(described in more detail below). However, there are many cases where we
don’t have a single reflection, we have a range of reflections - and we
want to splice them all in one go. For that, the predecessor to this
paper, [P1240R0], proposed an additional form of
splicer: a range splicer.
Construct the struct-to-tuple example from above. It was demonstrated using a single splice, but it would be simpler if we had a range splice:
With Single Splice
|
With Range Splice
|
---|---|
|
|
A range splice, [: ... r :]
,
would accept as its argument a constant range of
meta::info
,
r
, and would behave as an unexpanded
pack of splices. So the above expression
(t.[: ... members :]...) make_tuple
would evaluate as
(t.[:members[0]:], t.[:members[1]:], ..., t.[:members[N-1]:]) make_tuple
This is a very useful facility indeed!
However, range splicing of dependent arguments is at least an order of magnitude harder to implement than ordinary splicing. We think that not including range splicing gives us a better chance of having reflection in C++26. Especially since, as this paper’s examples demonstrate, a lot can be done without them.
Another way to work around a lack of range splicing would be to
implement with_size<N>(f)
,
which would behave like f(integral_constant<size_t, 0>{}, integral_constant<size_t, 1>{}, ..., integral_constant<size_t, N-1>{})
.
Which is enough for a tolerable implementation:
template <typename T> constexpr auto struct_to_tuple(T const& t) { constexpr auto members = nonstatic_data_members_of(^T); return with_size<members.size()>([&](auto... Is){ return std::make_tuple(t.[: members[Is] :]...); }); }
Early discussions of splice-like constructs (related to the TS
design) considered using unreflexpr(...)
for that purpose. [P1240R0] adopted that option for
expression splicing, observing that a single splicing syntax
could not viably be parsed (some disambiguation is needed to distinguish
types and templates). SG-7 eventually agreed to adopt the [: ... :]
syntax — with disambiguating tokens such as
typename
where needed — which is a little lighter and more distinctive.
We propose
[:
and
:]
be single
tokens rather than combinations of
[
,
]
, and
:
. Among
others, it simplifies the handling of expressions like arr[[:refl():]]
.
On the flip side, it requires a special rule like the one that was made
to handle
<::
to
leave the meaning of arr[::N]
unchanged and another one to avoid breaking a (somewhat useless)
attribute specifier of the form [[using ns:]]
.
A syntax that is delimited on the left and right is useful here because spliced expressions may involve lower-precedence operators. Additionally, it’s important that the left- and right-hand delimiters are different so as to allow nested splices when that comes up.
However, there are other possibilities. For example, now that
$
or
@
are available in the basic source
character set, we might consider those. One option that was recently
brought up was @ primary-expression
which would allow writing
@e
for the
simple identifier
splices
but for the more complex operations still require parenthesizing for
readability. $<expr>
is somewhat natural to those of us that have used systems where
$
is used to expand placeholders in
document templates:
[::]
|
[: :]
(with space)
|
@
|
$
|
---|---|---|---|
[:refl:] |
[: refl :] |
@refl |
$refl |
[:type_of(refl):] |
[: type_of(refl) :] |
@(type_of(refl)) |
$(type_of(refl)) |
There are two other pieces of functionality that we will probably need syntax for in the future:
+
as an
annotation introducer, but
+
can begin
an expression so another token is probably better. See also: this
thread).So any syntax discussion needs to consider the entirety of the feature.
The prefixes
typename
and
template
are
only strictly needed in some cases where the operand of the splice is a
dependent expression. In our proposal, however, we only make
typename
optional in the same contexts where it would be optional for qualified
names with dependent name qualifiers. That has the advantage to catch
unfortunate errors while keeping a single rule and helping human readers
parse the intended meaning of otherwise ambiguous constructs.
std::meta::info
The type std::meta::info
can be defined as follows:
namespace std { namespace meta { using info = decltype(^::); } }
In our initial proposal a value of type std::meta::info
can represent:
We for now restrict the space of reflectable values to those of structural type in order to meet two requirements:
Values of structural types can already be used as template arguments
(so implementations must already know how to mangle them), and the
notion of template-argument-equivalent values defined on the
class of structural types helps guarantee that &fn<^value1> == &fn<^value2>
if and only if &fn<value1> == &fn<value2>
.
Notably absent at this time are reflections of expressions. For example, one might wish to walk over the subexpressions of a function call:
template <typename T> void fn(T) {} void g() { constexpr auto call = ^(fn(42)); static_assert( (function_of(call))[0] == template_arguments_of^int); }
Previous revisions of this proposal suggested limited support for reflections of constant expressions. The introduction of side effects from constant evaluations (by this very paper), however, renders this roughly as difficult for constant expressions as it is for non-constant expressions. We instead defer all expression reflection to a future paper, and only present value and object reflection in the present proposal.
The type std::meta::info
is a scalar type for which equality and inequality are
meaningful, but for which no ordering relation is defined.
static_assert(^int == ^int); static_assert(^int != ^const int); static_assert(^int != ^int &); using Alias = int; static_assert(^int != ^Alias); static_assert(^int == dealias(^Alias)); namespace AliasNS = ::std; static_assert(^::std != ^AliasNS); static_assert(^:: == parent_of(^::std));
When the
^
operator
is followed by an id-expression, the resulting std::meta::info
reflects the entity named by the expression. Such reflections are
equivalent only if they reflect the same entity.
int x; struct S { static int y; }; static_assert(^x == ^x); static_assert(^x != ^S::y); static_assert(^S::y == static_data_members_of(^S)[0]);
Special rules apply when comparing certain kinds of reflections. A
reflection of an alias compares equal to another reflection if and only
if they are both aliases, alias the same type, and share the same name
and scope. In particular, these rules allow e.g., fn<^std::string>
to refer to the same instantiation across translation units.
using Alias1 = int; using Alias2 = int; consteval std::meta::info fn() { using Alias1 = int; return ^Alias; } static_assert(^Alias1 == ^Alias1); static_assert(^Alias1 != ^int); static_assert(^Alias1 != ^Alias2); static_assert(^Alias1 != fn()); }
A reflection of an object (including variables) does not compare equally to a reflection of its value. Two values of different types never compare equally.
constexpr int i = 42, j = 42; constexpr std::meta::info r = ^i, s = ^i; static_assert(r == r && r == s); static_assert(^i != ^j); // 'i' and 'j' are different entities. static_assert(value_of(^i) == value_of(^j)); // Two equivalent values. static_assert(^i != std::meta::reflect_object(i)) // A variable is distinct from the // object it designates. static_assert(^i != std::meta::reflect_value(42)); // A reflection of an object // is not the same as its value.
Nontype template arguments of type std::meta::info
are permitted (and frequently useful!), but since reflections represent
internal compiler state while processing a single translation unit, they
cannot be allowed to leak across TUs. Therefore both variables of
consteval-only type, and entities specialized by a non-type
template argument of consteval-only type, cannot have module or
external linkage (i.e., they must have either internal or no linkage).
While this can lead to some code bloat, we aren’t aware of any organic
use cases for reflection that are harmed by this limitation.
A corollary of this rule is that static data members of a class cannot have consteval-only types - such members always have external linkage, and to do otherwise would be an ODR violation. Again, we aren’t aware of any affected use-cases that absolutely require this.
template<auto R> struct S {}; int x; auto fn() { int k; return ^k; } static auto r = ^int; // r has internal name linkage. <^x> sx; // S<^x> has internal name linkage. S<fn()> sy; // S<^y> has internal name linkage. S
std::meta
namespaceThe namespace
std::meta
is
an associated type of std::meta::info
,
which allows standard library meta functions to be invoked without
explicit qualification. For example:
#include <meta> struct S {}; ::string name2 = std::meta::name_of(^S); // Okay. std::string name1 = name_of(^S); // Also okay. std
Default constructing or value-initializing an object of type std::meta::info
gives it a null reflection value. A null reflection value is equal to
any other null reflection value and is different from any other
reflection that refers to one of the mentioned entities. For
example:
#include <meta> struct S {}; static_assert(std::meta::info() == std::meta::info()); static_assert(std::meta::info() != ^S);
We propose a number of metafunctions declared in namespace
std::meta
to
operator on reflection values. Adding metafunctions to an implementation
is expected to be relatively “easy” compared to implementing the core
language features described previously. However, despite offering a
normal consteval C++ function interface, each on of these relies on
“compiler magic” to a significant extent.
In C++23, “constant evaluation” produces pure values without observable side-effects and thus the order in which constant-evaluation occurs is immaterial. In fact, while the language is designed to permit constant evaluation to happen at compile time, an implementation is not strictly required to take advantage of that possibility.
Some of the proposed metafunctions, however, have side-effects that
have an effect on the remainder of the program. For example, we provide
a define_class
metafunction that
provides a definition for a given class. Clearly, we want the effect of
calling that metafunction to be “prompt” in a lexical-order sense. For
example:
#include <meta> struct S; void g() { static_assert(is_type(define_class(^S, {}))); // S should be defined at this point. S s; }
Hence this proposal also introduces constraints on constant evaluation as follows…
First, we identify a subset of manifestly constant-evaluated expressions and conversions characterized by the fact that their evaluation must occur and must succeed in a valid C++ program: We call these plainly constant-evaluated. We require that a programmer can count on those evaluations occurring exactly once and completing at translation time.
Second, we sequence plainly constant-evaluated expressions and conversions within the lexical order. Specifically, we require that the evaluation of a plainly constant-evaluated expression or conversion occurs before the implementation checks the validity of source constructs lexically following that expression or conversion.
Those constraints are mostly intuitive, but they are a significant change to the underlying principles of the current standard in this respect.
[P2758R1] (“Emitting messages at compile time”) also has to deal with side effects during constant evaluation. However, those effects (“output”) are of a slightly different nature in the sense that they can be buffered until a manifestly constant-evaluated expression/conversion has completed. “Buffering” a class type completion is not practical (e.g., because other metafunctions may well depend on the completed class type). Still, we are not aware of incompatibilities between our proposal and [P2758R1].
Earlier revisions of this proposal suggested several possible
approaches to handling errors in reflection metafunctions. This question
arises naturally when considering, for instance, examples like template_of(^int)
:
the argument is a reflection of a type, but that type is not a
specialization of a template, so there is no valid reflected template
for us to return.
Some of the possibilities that we have considered include:
NaN
for floating point) which
carries source location info and some useful message (i.e., the approach
suggested by P1240)std::expected<std::meta::info, E>
for some reflection-specific error type
E
, which carries source location
info and some useful messageE
,
which requires a language extension for such exceptions to be catchable
during
constexpr
evaluationWe found that we disliked (1) since there is no satisfying value that
can be returned for a call like template_arguments_of(^int)
:
We could return a std::vector<std::meta::info>
having a single invalid reflection, but this makes for awkward error
handling. The experience offered by (3) is at least consistent, but
provides no immediate means for a user to “recover” from an error.
Either std::expected
or
constexpr exceptions would allow for a consistent and straightforward
interface. Deciding between the two, we noticed that many of usual
concerns about exceptions do not apply during translation:
An interesting example illustrates one reason for our preference for
exceptions over std::expected
:
template <typename T> requires (template_of(^T) == ^std::optional) void foo();
If template_of
returns an
expected<info, E>
,
then foo<int>
is a substitution failure — expected<T, E>
is equality-comparable to T
, that
comparison would evaluate to
false
but
still be a constant expression.
If template_of
returns
info
but throws an exception, then
foo<int>
would cause that exception to be uncaught, which would make the
comparison not a constant expression. This actually makes the constraint
ill-formed - not a substitution failure. In order to have foo<int>
be a substitution failure, either the constraint would have to first
check that T
is a template or we
would have to change the language rule that requires constraints to be
constant expressions (we would of course still keep the requirement that
the constraint is a
bool
).
Since the R2 revision of this paper, [P3068R1] has proposed the introduction of constexpr exceptions. The proposal addresses hurdles like compiler modes that disable exception support, and a Clang-based implementation is underway. We believe this to be the most desirable error-handling mechanism for reflection metafunctions.
Because constexpr exceptions have not yet been adopted into the
working draft, we do not specify any functions in this paper that throw
exceptions. Rather, we propose that they fail to be constant expressions
(i.e., case 3 above), and note that this approach will allow us to
forward-compatibly add exceptions at a later time. In the interim
period, implementations should have all of the information needed to
issue helpful diagnostics (e.g., “note:
R
does not reflect a template
specialization”) to improve the experience of writing reflection
code.
There are a number of functions, both in the “core” reflection API
that we intend to provide as well as converting some of the standard
library type traits that can accept or return a range of std::meta::info
.
For example:
template_arguments_of(^std::tuple<int>)
is {^int}
substitute(^std::tuple, {^int})
is ^std::tuple<int>
This requires us to answer the question: how do we accept a range parameter and how do we provide a range return.
For return, we intend on returning std::vector<std::meta::info>
from all such APIs. This is by far the easiest for users to deal with.
We definitely don’t want to return a std::span<std::meta::info const>
,
since this requires keeping all the information in the compiler memory
forever (unlike
std::vector
which could free its allocation). The only other option would be a
custom container type which is optimized for compile-time by being able
to produce elements lazily on demand - i.e. so that nonstatic_data_members_of(^T)[3]
wouldn’t have to populate all the data members, just do enough
work to be able to return the 4th one. But that adds a lot of complexity
that’s probably not worth the effort.
For parameters, there are basically three options:
std::span<std::meta::info const>
,
which now accepts braced-init-list arguments so it’s pretty convenient
in this regard.std::vector<std::meta::info>
type_value
is std::meta::info
.Now, for compiler efficiency reasons, it’s definitely better to have
all the arguments contiguously. So the compiler wants
span
. There’s really no reason to
prefer vector
over
span
. Accepting any range would look
something like this:
namespace std::meta { template <typename R> concept reflection_range = ranges::input_range<R> && same_as<ranges::range_value_t<R>, info>; template <reflection_range R = span<info const>> consteval auto substitute(info tmpl, R&& args) -> info; }
This API is more user friendly than accepting span<info const>
by virtue of simply accepting more kinds of ranges. The default template
argument allows for braced-init-lists to still work. Example.
Specifically, if the user is doing anything with range adaptors, they
will either end up with a non-contiguous or non-sized range, which will
no longer be convertible to span
-
so they will have to manually convert their range to a vector<info>
in order to pass it to the algorithm. Because the implementation wants
contiguity anyway, that conversion to
vector
will happen either way - so
it’s just a matter of whether every call needs to do it manually or the
implementation can just do it once.
For example, converting a struct to a tuple type:
span only
|
any range
|
---|---|
|
|
This shouldn’t cause much compilation overhead. Checking
convertibility to span
already uses Ranges machinery. And implementations can just do
the right thing interally:
consteval auto __builtin_substitute(info tmpl, info const* arg, size_t num_args) -> info; template <reflection_range R = span<info const>> consteval auto substitute(info tmpl, R&& args) -> info { if constexpr (ranges::sized_range<R> && ranges::contiguous_range<R>) { auto as_span = span<info const>(args); return __builtin_substitute(tmpl, as_span.data(), as_span.size()); } else { auto as_vector = ranges::to<vector<info>>((R&&)args); return __builtin_substitute(tmpl, as_vector.data(), as_vector.size()); } }
As such, we propose that all the range-accepting algorithms accept any range.
Consider
using A = int;
In C++ today, A
and
int
can be
used interchangeably and there is no distinction between the two types.
With reflection as proposed in this paper, that will no longer be the
case. ^A
yields a reflection of an alias to
int
, while
^int
yields a reflection of
int
. ^A == ^int
evaluates to
false
, but
there will be a way to strip aliases - so dealias(^A) == ^int
evaluates to
true
.
This opens up the question of how various other metafunctions handle aliases and it is worth going over a few examples:
using A = int; using B = std::unique_ptr<int>; template <class T> using C = std::unique_ptr<T>;
This paper is proposing that:
is_type(^A)
is true
.
^A
is an
alias, but it’s an alias to a type, and if this evaluated as
false
then
everyone would have to dealias
everything all the time.has_template_arguments(^B)
is false
while has_template_arguments(^C<int>)
is true
.
Even though B
is an alias to a type
that itself has template arguments (unique_ptr<int>
),
B
itself is simply a type alias and
does not. This reflects the actual usage.template_arguments_of(^C<int>)
yields {^int}
while template_arguments_of(^std::unique_ptr<int>)
yields {^int, ^std::default_deleter<int>}
.
This is because C
has its own
template arguments that can be reflected on.One of the most “obvious” abilities of reflection — retrieving the name of an entity — turns out to raise issues that aren’t obvious at all: How do we represent source text in a C++ program.
Thanks to recent work originating in SG16 (the “Unicode” study group)
we can assume that all source code is ultimately representable as
Unicode code points. C++ now also has types to represent UTF-8-encoded
text
(incl. char8_t
,
u8string
, and
u8string_view
) and corresponding
literals like u8"Hi"
.
Unfortunately, what can be done with those types is still limited at the
time of this writing. For example,
#include <iostream> int main() { ::cout << u8"こんにちは世界\n"; std}
is not standard C++ because the standard output stream does not have support for UTF-8 literals.
In practice ordinary strings encoded in the “ordinary string literal encoding” (which may or may not be UTF-8) are often used. We therefore need mechanisms to produce the corresponding ordinary string types as well.
Orthogonal to the character representation is the data structure used to traffic in source text. An implementation can easily have at least three potential representations of reflected source text:
the internal representation used, e.g., in the compiler front end’s AST-like structures (persistent)
the representation of string literals in the AST (persistent)
the representation of array of character values during constant-evaluation (transient)
(some compilers might share some of those representations). For
transient text during constant evaluation we’d like to use
string
/u8string
values, but because of the limitations on non-transient allocation
during constant evaluation we cannot easily transfer such types to the
non-constant (i.e., run-time) environment. E.g., if
name_of
were a (consteval)
metafunction returning a
std::string
value, the following simple example would not work:
#include <iostream> #include <meta> int main() { int hello_world = 42; ::cout << name_of(^hello_world) << "\n"; // Doesn't work if name_of produces a std::string. std}
We can instead return a std::string_view
or std::u8string_view
,
but that has the downside that it effectively makes all results of
querying source text persistent for the compilation.
For now, however, we propose that queries like
name_of
do produce “string view”
results. For example:
consteval std::string_view name_of(info); consteval std::u8string_view name_of(info);
An alternative strategy that we considered is the introduction of a “proxy type” for source text:
namespace std::meta { struct source_text_info { ... template<typename T> requires (^T == dealias(^std::string_view) || ^T == dealias(^std::u8string_view) || ^T == dealias(^std::string) || ^T == dealias(^std::u8string)) consteval T as(); ... }; }
where the as<...>()
member function produces a string-like type as desired. That idea was
dropped, however, because it became unwieldy in actual use cases.
With a source text query like name_of(refl)
it is possible that the some source characters of the result are not
representable. We can then consider multiple options, including:
the query fails to evaluate,
any unrepresentable source characters are translated to a
different presentation, such as universal-character-names of the form
\u{ hex-number }
,
any source characters not in the basic source character set are translated to a different presentation (as in (2)).
Following much discussion with SG16, we propose #1: The query fails to evaluate if the identifier cannot be represented in the ordinary string literal encoding.
Several important metafunctions, such as std::meta::nonstatic_data_members_of
,
return a
std::vector
value. Unfortunately, that means that they are currently not usable in a
freestanding environment, but [P3295R0] currently proposes freestanding
std::vector
,
std::string
,
and std::allocator
in
constant evaluated contexts, explicitly to make the facilities proposed
by this paper work in freestanding.
Here is a synopsis for the proposed library API. The functions will be explained below.
namespace std::meta { using info = decltype(^::); template <typename R> concept reflection_range = /* see above */; // name and location consteval auto name_of(info r) -> string_view; consteval auto qualified_name_of(info r) -> string_view; consteval auto display_name_of(info r) -> string_view; consteval auto u8name_of(info r) -> u8string_view; consteval auto u8display_name_of(info r) -> u8string_view; consteval auto u8qualified_name_of(info r) -> u8string_view; consteval auto source_location_of(info r) -> source_location; // type queries consteval auto type_of(info r) -> info; consteval auto parent_of(info r) -> info; consteval auto dealias(info r) -> info; // object and value queries consteval auto object_of(info r) -> info; consteval auto value_of(info r) -> info; // template queries consteval auto template_of(info r) -> info; consteval auto template_arguments_of(info r) -> vector<info>; // member queries template<typename ...Fs> consteval auto members_of(info type_class, Fs ...filters) -> vector<info>; template<typename ...Fs> consteval auto bases_of(info type_class, Fs ...filters) -> vector<info>; consteval auto static_data_members_of(info type_class) -> vector<info>; consteval auto nonstatic_data_members_of(info type_class) -> vector<info>; consteval auto subobjects_of(info type_class) -> vector<info>; consteval auto enumerators_of(info type_enum) -> vector<info>; // member access consteval auto access_context() -> info; struct access_pair { consteval access_pair(info target, info from = access_context()); }; consteval auto is_accessible(access_pair p) -> bool; consteval auto is_accessible(info r, info from); template <typename Pred> consteval auto accessible_members_of(access_pair p, Pred pred); template <typename Pred> consteval auto accessible_members_of(info target, info from, Pred pred); template <typename... Preds> consteval auto accessible_members_of(access_pair p, ... preds) -> vector<info>; Predstemplate <typename... Preds> consteval auto accessible_members_of(info target, info from, ... preds) -> vector<info>; Predsconsteval auto accessible_members_of(access_pair p) -> vector<info>; consteval auto accessible_members_of(info target, info from) -> vector<info>; template <typename Pred> consteval auto accessible_bases_of(access_pair p, Pred pred); template <typename Pred> consteval auto accessible_bases_of(info target, info from, Pred pred); template <typename... Preds> consteval auto accessible_bases_of(access_pair p, ... preds) -> vector<info>; Predstemplate <typename... Preds> consteval auto accessible_bases_of(info target, info from, ... preds) -> vector<info>; Predsconsteval auto accessible_bases_of(access_pair p) -> vector<info>; consteval auto accessible_bases_of(info target, info from) -> vector<info>; consteval auto accessible_nonstatic_data_members_of(access_pair p) -> vector<info>; consteval auto accessible_nonstatic_data_members_of(info target, ) -> vector<info>; info fromconsteval auto accessible_static_data_members_of(access_pair p) -> vector<info>; consteval auto accessible_static_data_members_of(info target, ) -> vector<info>; info fromconsteval auto accessible_subobjects_of(access_pair p) -> vector<info>; consteval auto accessible_subobjects_of(info target, ) -> vector<info>; info from // substitute template <reflection_range R = span<info const>> consteval auto can_substitute(info templ, R&& args) -> bool; template <reflection_range R = span<info const>> consteval auto substitute(info templ, R&& args) -> info; // reflect_invoke template <reflection_range R = span<info const>> consteval auto reflect_invoke(info target, R&& args) -> info; template <reflection_range R1 = span<info const>, reflection_range R2 = span<info const>> consteval auto reflect_invoke(info target, R1&& tmpl_args, R2&& args) -> info; // reflect expression results template <typename T> consteval auto reflect_value(T value) -> info; template <typename T> consteval auto reflect_object(T& value) -> info; template <typename T> consteval auto reflect_function(T& value) -> info; // extract
template <typename T> consteval auto extract(info) -> T; // test_trait consteval auto test_trait(info templ, info type) -> bool; template <reflection_range R = span<info const>> consteval auto test_trait(info templ, R&& arguments) -> bool; // other type predicates (see the wording) consteval auto is_public(info r) -> bool; consteval auto is_protected(info r) -> bool; consteval auto is_private(info r) -> bool; consteval auto is_virtual(info r) -> bool; consteval auto is_pure_virtual(info entity) -> bool; consteval auto is_override(info entity) -> bool; consteval auto is_deleted(info entity) -> bool; consteval auto is_defaulted(info entity) -> bool; consteval auto is_explicit(info entity) -> bool; consteval auto is_noexcept(info entity) -> bool; consteval auto is_bit_field(info entity) -> bool; consteval auto is_const(info r) -> bool; consteval auto is_volatile(info r) -> bool; consteval auto is_final(info r) -> bool; consteval auto has_static_storage_duration(info r) -> bool; consteval auto has_internal_linkage(info r) -> bool; consteval auto has_module_linkage(info r) -> bool; consteval auto has_external_linkage(info r) -> bool; consteval auto has_linkage(info r) -> bool; consteval auto is_class_member(info entity) -> bool; consteval auto is_namespace_member(info entity) -> bool; consteval auto is_nonstatic_data_member(info entity) -> bool; consteval auto is_static_member(info entity) -> bool; consteval auto is_base(info entity) -> bool; consteval auto is_namespace(info entity) -> bool; consteval auto is_function(info entity) -> bool; consteval auto is_variable(info entity) -> bool; consteval auto is_type(info entity) -> bool; consteval auto is_alias(info entity) -> bool; consteval auto is_incomplete_type(info entity) -> bool; consteval auto is_template(info entity) -> bool; consteval auto is_function_template(info entity) -> bool; consteval auto is_variable_template(info entity) -> bool; consteval auto is_class_template(info entity) -> bool; consteval auto is_alias_template(info entity) -> bool; consteval auto is_concept(info entity) -> bool; consteval auto is_structured_binding(info entity) -> bool; consteval auto is_value(info entity) -> bool; consteval auto is_object(info entity) -> bool; consteval auto has_template_arguments(info r) -> bool; consteval auto is_constructor(info r) -> bool; consteval auto is_destructor(info r) -> bool; consteval auto is_special_member(info r) -> bool; consteval auto is_user_provided(info r) -> bool; // define_class struct data_member_options_t; consteval auto data_member_spec(info type_class, = {}) -> info; data_member_options_t options template <reflection_range R = span<info const>> consteval auto define_class(info type_class, R&&) -> info; // data layout consteval auto offset_of(info entity) -> size_t; consteval auto size_of(info entity) -> size_t; consteval auto alignment_of(info entity) -> size_t; consteval auto bit_offset_of(info entity) -> size_t; consteval auto bit_size_of(info entity) -> size_t; }
name_of
,
display_name_of
,
source_location_of
namespace std::meta { consteval auto name_of(info) -> string_view; consteval auto qualified_name_of(info) -> string_view; consteval auto display_name_of(info) -> string_view; consteval auto u8name_of(info) -> u8string_view; consteval auto u8qualified_name_of(info) -> u8string_view; consteval auto u8display_name_of(info) -> u8string_view; consteval auto source_location_of(info r) -> source_location; }
If a string_view
is returned, its
contents consist of characters representable by the ordinary string
literal encoding only; if any character cannot be represented, it is not
a constant expression.
Given a reflection r
that
designates a declared entity X
,
name_of(r)
and qualified_name_of(r)
return a string_view
holding the
unqualified and qualified name of X
,
respectively. u8name_of(r)
and qualified_name_of(r)
return the same, respectively, as a
u8string_view
. For all other
reflections, an empty string view is produced. For template instances,
the name does not include the template argument list.
Given a reflection r
, display_name_of(r)
and u8display_name_of(r)
return an unspecified non-empty
string_view
and
u8string_view
, respectively.
Implementations are encouraged to produce text that is helpful in
identifying the reflected construct.
Given a reflection r
, source_location_of(r)
returns an unspecified
source_location
. Implementations are
encouraged to produce the correct source location of the item designated
by the reflection.
type_of
,
parent_of
,
dealias
namespace std::meta { consteval auto type_of(info r) -> info; consteval auto parent_of(info r) -> info; consteval auto dealias(info r) -> info; }
If r
is a reflection designating
a typed entity, type_of(r)
is a reflection designating its type. If
r
is already a type, type_of(r)
is not a constant expression. This can be used to implement the C
typeof
feature (which works on both types and expressions and strips
qualifiers):
consteval auto type_doof(std::meta::info r) -> std::meta::info { return type_remove_cvref(is_type(r) ? r : type_of(r)); } #define typeof(e) [: type_doof(^e) :]
If r
designates a member of a
class or namespace, parent_of(r)
is a reflection designating its immediately enclosing class or (possibly
inline or anonymous) namespace.
If r
designates an alias, dealias(r)
designates the underlying entity. Otherwise, dealias(r)
produces r
.
dealias
is recursive - it strips all
aliases:
using X = int; using Y = X; static_assert(dealias(^int) == ^int); static_assert(dealias(^X) == ^int); static_assert(dealias(^Y) == ^int);
object_of
,
value_of
namespace std::meta { consteval auto object_of(info r) -> info; consteval auto value_of(info r) -> info; }
If r
is a reflection of a
variable denoting an object with static storage duration, then object_of(r)
is a reflection of the object designated by the variable. If
r
is already a reflection of an
object, object_of(r)
is r
. For all other inputs, object_of(r)
is not a constant expression.
int x; int &y = x; static_assert(^x != ^y); static_assert(object_of(^x) == object_of(^y));
If r
is a reflection of an
enumerator, then value_of(r)
is a reflection of the value of the enumerator. Otherwise, if
r
is a reflection of an object
usable in constant expressions, then value_of(r)
is a reflection of the value of the object. For all other inputs, value_of(r)
is not a constant expression.
template_of
,
template_arguments_of
namespace std::meta { consteval auto template_of(info r) -> info; consteval auto template_arguments_of(info r) -> vector<info>; }
If r
is a reflection designating
a specialization of some template, then template_of(r)
is a reflection of that template and template_arguments_of(r)
is a vector of the reflections of the template arguments. In other
words, the preconditions on both is that has_template_arguments(r)
is true
.
For example:
::vector<int> v = {1, 2, 3}; stdstatic_assert(template_of(type_of(^v)) == ^std::vector); static_assert(template_arguments_of(type_of(^v))[0] == ^int);
members_of
,
static_data_members_of
,
nonstatic_data_members_of
,
bases_of
,
enumerators_of
,
subobjects_of
namespace std::meta { template<typename ...Fs> consteval auto members_of(info type_class, Fs ...filters) -> vector<info>; template<typename ...Fs> consteval auto bases_of(info type_class, Fs ...filters) -> vector<info>; consteval auto static_data_members_of(info type_class) -> vector<info> { return members_of(type_class, is_variable); } consteval auto nonstatic_data_members_of(info type_class) -> vector<info> { return members_of(type_class, is_nonstatic_data_member); } consteval auto subobjects_of(info type_class) -> vector<info> { auto subobjects = bases_of(type_class); .append_range(nonstatic_data_members_of(type_class)); subobjectsreturn subobjects; } consteval auto enumerators_of(info type_enum) -> vector<info>; }
The template members_of
returns a
vector of reflections representing the direct members of the class type
represented by its first argument. Any non-static data members appear in
declaration order within that vector. Anonymous unions appear as a
non-static data member of corresponding union type. Reflections of
structured bindings shall not appear in the returned vector. If any
Filters...
argument is specified, a member is dropped from the result if any filter
applied to that members reflection returns
false
. E.g.,
members_of(^C, std::meta::is_type)
will only return types nested in the definition of
C
and members_of(^C, std::meta::is_type, std::meta::is_variable)
will return an empty vector since a member cannot be both a type and a
variable.
The template bases_of
returns the
direct base classes of the class type represented by its first argument,
in declaration order.
static_data_members_of
and
nonstatic_data_members_of
return the
equivalent of members_of(^C, std::meta::is_nonstatic_data_member)
and members_of(^C, std::meta::is_variable)
,
respectively.
subobjects_of
returns the base
class subobjects and the non-static data members of a type, in
declaration order. Note that the term subobject
also includes array elements, which we are excluding here. Such
reflections would currently be of minimal use since you could not splice
them with access (e.g. arr.[:elem:]
is not supported), so would need some more thought first.
enumerators_of
returns the
enumerator constants of the indicated enumeration type in declaration
order.
namespace std::meta { consteval auto access_context() -> info; struct access_pair { consteval access_pair(info target, info from = access_context()); }; consteval auto is_accessible(access_pair p) -> bool; template<typename ...Fs> consteval auto accessible_members_of(access_pair p, Fs ...filters) -> vector<info>; template<typename ...Fs> consteval auto accessible_members_of(info target, info from, Fs ...filters) -> vector<info>; template<typename ...Fs> consteval auto accessible_bases_of(access_pair p, Fs ...filters) -> vector<info>; template<typename ...Fs> consteval auto accessible_bases_of(info target, info from, Fs ...filters) -> vector<info>; consteval auto accessible_static_data_members_of(access_pair p) -> vector<info>; consteval auto accessible_static_data_members_of(info target, info from) -> vector<info>; consteval auto accessible_nonstatic_data_members_of(access_pair p) -> vector<info>; consteval auto accessible_nonstatic_data_members_of(info target, info from) -> vector<info>; consteval auto accessible_subobjects_of(access_pair p) -> vector<info>; consteval auto accessible_subobjects_of(info target, info from) -> vector<info>; }
The access_context()
function returns a reflection of the function, class, or namespace whose
scope encloses the function call.
The type access_pair
represents
the operands of a check for access to
target
from the scope introduced by
the function, class, or namespace reflected by
from
. If
from
is not specified, the
access_pair
constructor captures the
current access context of the caller via the default argument. Each
function also provides an overload whereby
target
and
from
may be specified as distinct
arguments.
Each function named
accessible_meow_of
returns the
result of meow_of
filtered on
is_accessible
.
For example:
class C { int k; static_assert(is_accessible(^C::k)); // ok: context is 'C'. friend void fn(); } static_assert(accessible_subobjects_of(^C).size() == 0); static_assert(accessible_subobjects_of(^C, ^fn).size() == 1);
substitute
namespace std::meta { template <reflection_range R = span<info const>> consteval auto can_substitute(info templ, R&& args) -> bool; template <reflection_range R = span<info const>> consteval auto substitute(info templ, R&& args) -> info; }
Given a reflection for a template and reflections for template
arguments that match that template,
substitute
returns a reflection for
the entity obtained by substituting the given arguments in the template.
If the template is a concept template, the result is a reflection of a
constant of type
bool
.
For example:
constexpr auto r = substitute(^std::vector, std::vector{^int}); using T = [:r:]; // Ok, T is std::vector<int>
This process might kick off instantiations outside the immediate context, which can lead to the program being ill-formed.
Note that the template is only substituted, not instantiated. For example:
template<typename T> struct S { typename T::X x; }; constexpr auto r = substitute(^S, std::vector{^int}); // Okay. typename[:r:] si; // Error: T::X is invalid for T = int.
can_substitute(templ, args)
simply checks if the substitution can succeed (with the same caveat
about instantiations outside of the immediate context). If can_substitute(templ, args)
is false
,
then substitute(templ, args)
will be ill-formed.
reflect_invoke
namespace std::meta { template <reflection_range R = span<info const>> consteval auto reflect_invoke(info target, R&& args) -> info; template <reflection_range R1 = span<info const>, reflection_range R2 = span<info const>> consteval auto reflect_invoke(info target, R1&& tmpl_args, R2&& args) -> info; }
These metafunctions produce a reflection of the result of a call expression.
For the first overload: Letting F
be the entity reflected by target
,
and A0, A1, ..., AN
be the sequence of entities reflected by the values held by
args
: if the expression F(A0, A1, ..., AN)
is a well-formed constant expression evaluating to a structural type
that is not
void
, and if
every value in args
is a reflection
of a value or object usable in constant expressions, then reflect_invoke(target, args)
evaluates to a reflection of the result of F(A0, A1, ..., AN)
.
For all other invocations, reflect_invoke(target, args)
is not a constant expression.
The second overload behaves the same as the first overload, except
instead of evaluating F(A0, A1, ..., AN)
,
we require that F
be a reflection of
a template and evaluate F<T0, T1, ..., TM>(A0, A1, ..., AN)
.
This allows evaluating reflect_invoke(^std::get, {std::meta::reflect_value(0)}, {e})
to evaluate to, approximately, ^std::get<0>([: e :])
.
If the returned reflection is of a value (rather than an object), the type of the reflected value is the cv-qualified (de-aliased) type of what’s returned by the function.
A few possible extensions for
reflect_invoke
have been discussed
among the authors. Given the advent of constant evaluations with
side-effects, it may be worth allowing
void
-returning
functions, but this would require some representation of “a returned
value of type
void
”.
Construction of runtime call expressions is another exciting
possibility. Both extensions require more thought and implementation
experience, and we are not proposing either at this time.
reflect_value
,
reflect_object
,
reflect_function
namespace std::meta { template<typename T> consteval auto reflect_value(T expr) -> info; template<typename T> consteval auto reflect_object(T& expr) -> info; template<typename T> consteval auto reflect_function(T& expr) -> info; }
These metafunctions produce a reflection of the result from
evaluating the provided expression. One of the most common use-cases for
such reflections is to specify the template arguments with which to
build a specialization using std::meta::substitute
.
reflect_value(expr)
produces a reflection of the value computed by an lvalue-to-rvalue
conversion on expr
. The type of the
reflected value is the cv-unqualified (de-aliased) type of
expr
. The result needs to be a
permitted result of a constant expression, and
T
cannot be of reference type.
static_assert(substitute(^std::array, {^int, std::meta::reflect_value(5)}) ==
^std::array<int, 5>);
reflect_object(expr)
produces a reflection of the object designated by
expr
. This is frequently used to
obtain a reflection of a subobject, which might then be used as a
template argument for a non-type template parameter of reference
type.
template <int &> void fn();
int p[2];
constexpr auto r = substitute(^fn, {std::meta::reflect_object(p[1])});
reflect_function(expr)
produces a reflection of the function designated by
expr
. It can be useful for
reflecting on the properties of a function for which only a reference is
available.
consteval bool is_global_with_external_linkage(void(*fn)()) {
::meta::info rfn = std::meta::reflect_function(*fn);
std
return (has_external_linkage(rfn) && parent_of(rfn) == ^::);
}
extract<T>
namespace std::meta { template<typename T> consteval auto extract(info) -> T; }
If r
is a reflection for a value
of type T
, extract<T>(r)
is a prvalue whose evaluation computes the reflected value.
If r
is a reflection for an
object of non-reference type T
,
extract<T&>(r)
and extract<T const&>(r)
are lvalues referring to that object. If the object is usable in
constant expressions [expr.const], extract<T>(r)
evaluates to its value.
If r
is a reflection for an
object of reference type T
usable in
constant-expressions, extract<T>(r)
evaluates to that reference.
If r
is a reflection for a
function of type F
, extract<F*>(r)
evaluates to a pointer to that function.
If r
is a reflection for a
non-static member function and T
is
the type for a pointer to the reflected member function, extract<T>(r)
evaluates to a pointer to the member function.
If r
is a reflection for an
enumerator constant of type E
, extract<E>(r)
evaluates to the value of that enumerator.
If r
is a reflection for a
non-bit-field non-reference non-static member of type
M
in a class
C
, extract<M C::*>(r)
is the pointer-to-member value for that non-static member.
For other reflection values r
,
extrace<T>(r)
is ill-formed.
The function template extract
may
feel similar to splicers, but unlike splicers it does not require its
operand to be a constant-expression itself. Also unlike splicers, it
requires knowledge of the type associated with the entity reflected by
its operand.
test_trait
namespace std::meta { consteval auto test_trait(info templ, info type) -> bool { return test_trait(templ, {type}); } template <reflection_range R = span<info const>> consteval auto test_trait(info templ, R&& types) -> bool { return extract<bool>(substitute(templ, (R&&)types)); } }
This utility translates existing metaprogramming predicates (expressed as constexpr variable templates or concept templates) to the reflection domain. For example:
struct S {}; static_assert(test_trait(^std::is_class_v, ^S)); static_assert(test_trait(^std::is_same_v, {^S, ^S})
An implementation is permitted to recognize standard predicate
templates and implement test_trait
without actually instantiating the predicate template. In fact, that is
recommended practice.
data_member_spec
,
define_class
namespace std::meta { struct data_member_options_t { struct name_type { template <typename T> requires constructible_from<u8string, T> consteval name_type(T &&); template <typename T> requires constructible_from<string, T> consteval name_type(T &&); }; <name_type> name; optional<int> alignment; optional<int> width; optionalbool no_unique_address = false; }; consteval auto data_member_spec(info type, = {}) -> info; data_member_options_t options template <reflection_range R = span<info const>> consteval auto define_class(info type_class, R&&) -> info; }
data_member_spec
returns a
reflection of a description of a data member of given type. Optional
alignment, bit-field-width, static-ness, and name can be provided as
well. An inner class name_type
,
which may be implicitly constructed from any of several “string-like”
types (e.g., string_view
,
u8string_view
, char8_t[]
,
char_t[]
),
is used to represent the name. If a
name
is provided, it must be a valid
identifier when interpreted as a sequence of UTF-8 code-units (after
converting any contained UCNs to UTF-8). Otherwise, the name of the data
member is unspecified.
define_class
takes the reflection
of an incomplete class/struct/union type and a range of reflections of
data member descriptions and completes the given class type with data
members as described (in the given order). The given reflection is
returned. For now, only data member reflections are supported (via
data_member_spec
) but the API takes
in a range of info
anticipating
expanding this in the near future.
For example:
union U; static_assert(is_type(define_class(^U, { (^int), data_member_spec(^char), data_member_spec(^double), data_member_spec}))); // U is now defined to the equivalent of // union U { // int _0; // char _1; // double _2; // }; template<typename T> struct S; constexpr auto s_int_refl = define_class(^S<int>, { (^int, {.name="i", .alignment=64}), data_member_spec(^int, {.name=u8"こんにち", .alignment=64}), data_member_spec(^int, {.name="v\\N{LATIN SMALL LETTER AE}rs\\u{e5}god"}) data_member_spec}); // S<int> is now defined to the equivalent of // template<> struct S<int> { // alignas(64) int i; // alignas(64) int こんにち; // int værsågod; // };
When defining a
union
, if
one of the alternatives has a non-trivial destructor, the defined union
will still have a destructor provided - that simply does
nothing. This allows implementing variant without having to further
extend support in define_class
for
member functions.
If type_class
is a reflection of
a type that already has a definition, or which is in the process of
being defined, the call to
define_class
is not a constant
expression.
namespace std::meta { consteval auto offset_of(info entity) -> size_t; consteval auto size_of(info entity) -> size_t; consteval auto alignment_of(info entity) -> size_t; consteval auto bit_offset_of(info entity) -> size_t; consteval auto bit_size_of(info entity) -> size_t; }
These are generalized versions of some facilities we already have in the language.
offset_of
takes a reflection of
a non-static data member or a base class subobject and returns the
offset of it.size_of
takes the reflection of
a type, object, variable, non-static data member, or base class
subobject and returns its size.alignment_of
takes the
reflection of a type, non-static data member, or base class subobject
and returns its alignment.bit_size_of
and
bit_offset_of
give the size and
offset of a base class subobject or non-static data member, except in
bits. Note that the bit_offset_of
is
a value between
0
and
7
,
inclusive:struct Msg { uint64_t a : 10; uint64_t b : 8; uint64_t c : 25; uint64_t d : 21; }; static_assert(bit_offset_of(^Msg::a) == 0); static_assert(bit_offset_of(^Msg::b) == 2); static_assert(bit_offset_of(^Msg::c) == 2); static_assert(bit_offset_of(^Msg::d) == 3); static_assert(bit_size_of(^Msg::a) == 10); static_assert(bit_size_of(^Msg::b) == 8); static_assert(bit_size_of(^Msg::c) == 25); static_assert(bit_size_of(^Msg::d) == 21); consteval auto total_bit_offset_of(std::meta::info m) -> size_t { return offset_of(m) * 8 + bit_offset_of(m); } static_assert(total_bit_offset_of(^Msg::a) == 0); static_assert(total_bit_offset_of(^Msg::b) == 10); static_assert(total_bit_offset_of(^Msg::c) == 18); static_assert(total_bit_offset_of(^Msg::d) == 43);
There is a question of whether all the type traits should be provided
in
std::meta
.
For instance, a few examples in this paper use std::meta::type_remove_cvref(t)
as if that exists. Technically, the functionality isn’t strictly
necessary - since it can be provided indirectly:
Direct
|
Indirect
|
---|---|
|
|
|
|
Having std::meta::meow
for every trait
std::meow
is
more straightforward and will likely be faster to compile, though means
we will have a much larger library API. There are quite a few traits in
21 [meta] - but it
should be easy enough to specify all of them. So we’re doing it.
Now, one thing that came up is that the straightforward thing we want
to do is to simply add a std::meta::meow
for every trait
std::meow
and word it appropriately. That’s what the current wording in this
revision does. However, we’ve run into a conflict. The standard library
type traits are all type traits - they only accept types. As
such, their names are simply things like std::is_pointer
,
std::is_const
,
std::is_lvalue_reference
,
and so forth. Renaming it to std::type_is_pointer
,
for instance, would be a waste of characters since there’s nothing else
the argument could be save for a type. But this is no longer the case.
Consider std::meta::is_function(e)
,
which is currently actually specified twice in our wording having two
different meanings:
std::is_function<T>
,
such that std::meta::is_function(e)
mandates that e
reflect a type and
checks if that type is a function type. This is the same category of
type trait as the ones mentioned above.std::meta::is_function(e)
which asks if e
is the reflection of
a function (as opposed to a type or a namespace or a template, etc.).
This is the same category of query as std::meta::is_template
or std::meta::is_concept
or std::meta::is_namespace
.Both of these are useful, yet they mean different things entirely -
the first is ill-formed when passed a reflection of a function (as
opposed to a function type), and the second would simply answer
false
for
the reflection of any type (function type or otherwise). So
what do we do?
Probably the most straightforward choice would be to either prefix or
suffix all of the type traits with
_type
. We think prefix is a little
bit better because it groups all the type traits together and perhaps
make it clearer that the argument(s) must be types. That is: std::is_pointer<T>
because std::meta::type_is_pointer(^T)
,
std::is_arithmetic<T>
becomes std::meta::type_is_arithmetic(^T)
,
and so forth. The advantage of this approach is that it very likely just
works, also opening the door to making a more general std::meta::is_const(e)
that checks not just if e
is a
const
-qualified
type but also if it’s a
const
-qualified
object or a
const
-qualified
member, etc. The disadvantage is that the suffixed names would not be
familiar - we’re much more familiar with the name
is_copy_constructible
than we would
be with
type_is_copy_constructible
.
That said, it’s not too much added mental overhead to remember
type_is_copy_constructible
and this
avoids have to remember which type traits have the suffix and which
don’t. Not to mention that many of the type traits read as if
they would accept objects just fine
(e.g. is_trivially_copyable
). So we
propose that simply all the type traits be suffixed with
*_type
.
Static reflection invariably brings new ways to violate ODR.
// File 'cls.h'
struct Cls {
void odr_violator() {
if constexpr (members_of(parent_of(^std::size_t)).size() % 2 == 0)
();
branch_1else
();
branch_2}
};
Two translation units including
cls.h
can
generate different definitions of Cls::odr_violator()
based on whether an odd or even number of declarations have been
imported from std
. Branching on the
members of a namespace is dangerous because namespaces may be redeclared
and reopened: the set of contained declarations can differ between
program points.
The creative programmer will find no difficulty coming up with other
predicates which would be similarly dangerous if substituted into the
same if constexpr
condition: for instance, given a branch on is_incomplete_type(^T)
,
if one translation unit
#include
s a
forward declaration of T
, another
#include
s a
complete definition of T
, and they
both afterwards #include "cls.h"
,
the result will be an ODR violation.
Additional papers are already in flight proposing additional
metafunctions that pose similar dangers. For instance, [P3096R1] proposes the
parameters_of
metafunction. This
feature is important for generating language bindings (e.g., Python,
JavaScript), but since parameter names can differ between declarations,
it would be dangerous for a member function defined in a header file to
branch on the name of a parameter.
These cases are not difficult to identify: Given an entity
E
and two program points
P1
and
P2
from which a reflection of
E
may be optained, it is unsafe to
branch runtime code generation on any property of
E
(e.g., namespace members,
parameter names, completeness of a class) that can be modified between
P1
and
P2
. Worth noting as well, these
sharp edges are not unique (or new) to reflection: It is already
possible to build an ODR trap based on the completeness of a class using
C++23.
Education and training are important to help C++ users avoid such sharp edges, but we do not find them sufficiently concerning to give pause to our enthusiasm for the features proposed by this paper.
Modify the wording for phases 7-8 of 5.2 [lex.phases] as follows:
7 Whitespace characters separating tokens are no longer significant. Each preprocessing token is converted into a token (5.6). The resulting tokens constitute a translation unit and are syntactically and semantically analyzed and translated. Plainly constant-evaluated expressions ([expr.const]) appearing outside template declarations are evaluated in lexical order. Diagnosable rules (4.1.1 [intro.compliance.general]) that apply to constructs whose syntactic end point occurs lexically after the syntactic end point of a plainly constant-evaluated expression X are considered in a context where X has been evaluated. […]
8 […] All the required instantiations are performed to produce instantiation units. Plainly constant-evaluated expressions ([expr.const]) appearing in those instantiation units are evaluated in lexical order as part of the instantiation process. Diagnosable rules (4.1.1 [intro.compliance.general]) that apply to constructs whose syntactic end point occurs lexically after the syntactic end point of a plainly constant-evaluated expression X are considered in a context where X has been evaluated. […]
Add a bullet after 5.4 [lex.pptoken] bullet (3.2):
…
— Otherwise, if the next three characters are
<::
and the subsequent character is neither:
nor>
, the<
is treated as a preprocessing token by itself and not as the first character of the alternative token<:
.— Otherwise, if the next three characters are
[::
and the subsequent character is not:
or if the next three characters are[:>
, the[
is treated as a preprocessing token by itself and not as the first character of the preprocessing token[:
.…
Change the grammar for
operator-or-punctuator
in
paragraph 1 of 5.12 [lex.operators] to
include splicer delimiters:
operator-or-punctuator: one of
[: :]
{ } [ ] ( ) <: :> <% %> ; : ... ? :: . .* -> ->* ~ ! + - * / % ^ & | = += -= *= /= %= ^= &= |= == != < > <= >= <=> && || << >> <<= >>= ++ -- , and or xor not bitand bitor compl and_eq or_eq xor_eq not_eq
Modify paragraph 4.1 to cover splicing of functions:
- (4.1) A function is named by an expression or conversion if it is the selected member of an overload set ([basic.lookup], [over.match], [over.over]) in an overload resolution performed as part of forming that expression or conversion, or if it is denoted by a splice-expression ([expr.prim.splice]), unless it is a pure virtual function and either the expression is not an id-expression naming the function with an explicitly qualified name or the expression forms a pointer to member ([expr.unary.op]).
Modify the first sentence of paragraph 5 to cover splicing of variables:
- 5 A variable is named by an expression if the expression is an id-expression or splice-expression ([expr.prim.splice]) that denotes it.
Modify paragraph 6 to cover splicing of structured bindings:
- 6 A structured binding is odr-used if it appears as a potentially-evaluated expression, or if a reflection of it is the operand of a potentially-evaluated splice-expression ([expr.prim.splice]).
Prepend before paragraph 15 of 6.3 [basic.def.odr]:
15pre If a class
C
is defined in a translation unit with a call tostd::meta::define_class
, every definition of that class shall be the result of a call tostd::meta::define_class
such that its respective members are equal in number and have respectively the same types, alignments,[[no_unique_address]]
attributes (if any), bit-field widths (if any), and specified names (if any).15 Otherwise, for
Forany definable item D with definitions …
Add a bullet to paragraph 3 of 6.5.4 [basic.lookup.argdep]
as follows [ Editor's note:
this must precede the fundamental type bullet, because
meta::info
is a fundamental type
]:
3 … Any
typedef-name
s andusing-declaration
s used to specify the types do not contribute to this set. The set of entities is determined in the following way:
- (3.0) If
T
isstd::meta::info
, its associated set of entities is the singleton containing the functionstd::meta::is_type
.
Extend 6.5.5.1 [basic.lookup.qual.general]/1-2
to cover
splice-name-qualifer
:
1 Lookup of an identifier followed by a
::
scope resolution operator considers only namespaces, types, and templates whose specializations are types. If a name,template-id
,orcomputed-type-specifier
, orsplice-name-qualifier
is followed by a ::
, it shall designate a namespace, class, enumeration, or dependent type, and the :: is never interpreted as a complete nested-name-specifier.2 A member-qualified name is the (unique) component name ([expr.prim.id.unqual]), if any, of
- (2.1) an unqualified-id or
- (2.2) a
nested-name-specifier
of the formtype-name ::
or,namespace-name ::
, orsplice-name-qualifier ::
in the id-expression of a class member access expression ([expr.ref]). […]
Add a bullet to paragraph 4, and renumber accordingly:
4 An unnamed namespace or a namespace declared directly or indirectly within an unnamed namespace has internal linkage. All other namespaces have external linkage. The name of an entity that belongs to a namespace scope that has not been given internal linkage above and that is the name of * (4.1) a variable; or
…
has its linkage determined as follows:
- (4.7) if the enclosing namespace has internal linkage, the name has internal linkage;
- (4.8) otherwise, if the declaration of the name is attached to a named module ([module.unit]) and is not exported ([module.interface]), the name has module linkage;
- (4.9) otherwise, if the declaration is a variable having consteval-only type ([basic.types.general]), or is of a class template specialization type having a consteval-only type as a non-type template argument, the name has internal linkage.
- (4.10) otherwise, the name has external linkage.
Change the first sentence in paragraph 9 of 6.8.1 [basic.types.general] as follows:
9 Arithmetic types (6.8.2), enumeration types, pointer types, pointer-to-member types (6.8.4),
std::meta::info
,std::nullptr_t
, and cv-qualified (6.8.5) versions of these types are collectively called scalar types.
Add a new paragraph at the end of 6.8.1 [basic.types.general] as follows:
* A consteval-only type is one of the following:
std::meta::info
, or- a pointer or reference to a consteval-only type, or
- an (possibly multi-dimensional) array of a consteval-only type, or
- a pointer-to-member type to a class
C
of typeM
where eitherC
orM
is a consteval-only type, or- a function type with a consteval-only return type or a consteval-only parameter type, or
- a class type with a consteval-only base class type or consteval-only non-static data member type.
An object of consteval-only type shall either end its lifetime during the evaluation of a manifestly constant-evaluated expression or conversion (7.7 [expr.const]), or be a constexpr variable that is not odr-used (6.3 [basic.def.odr]).
* Consteval-only types may not be used to declare a static data member of a class having module or external linkage. Furthermore, specializations of a class template having a non-type template argument of consteval-only type may not be used to declare a static data member of a class having module or external linkage.
Add a new paragraph before the last paragraph of 6.8.2 [basic.fundamental] as follows:
* A value of type
std::meta::info
is called a reflection and represents a language element such as a type, a value, an object, a non-static data member, etc. An expression convertible tostd::meta::info
is said to reflect the language element represented by the resulting value; the language element is said to be reflected by the expression.sizeof(std::meta::info)
shall be equal tosizeof(void*)
. [ Note 1: Reflections are only meaningful during translation. The notion of consteval-only types (see 6.8.1 [basic.types.general]) exists to diagnose attempts at using such values outside the translation process. — end note ]
Change the grammar for
primary-expression
in
7.5 [expr.prim]
as follows:
primary-expression: literal this ( expression ) id-expression lambda-expression fold-expression requires-expression+ splice-expression + + splice-expression + [: constant-expression :] + template[: constant-expression :] < template-argument-listopt >
Add a production to the grammar for
nested-name-specifier
as
follows:
nested-name-specifier: :: type-name :: namespace-name :: computed-type-specifier ::+ splice-name-qualifier :: nested-name-specifier identifier :: nested-name-specifier templateopt simple-template-id ::+ + splice-name-qualifier: + [: constant-expression :]
Extend 7.5.4.3 [expr.prim.id.qual]/1 to also cover splices:
1 The component names of a
qualified-id
are those of itsnested-name-specifier
andunqualified-id
. The component names of anested-name-specifier
are itsidentifier
(if any) and those of itstype-name
,namespace-name
,simple-template-id
,and/ornested-name-specifier
, and/or thetype-name
ornamespace-name
of the entity reflected by theconstant-expression
of itssplice-name-qualifier
. For anested-name-specifier
having asplice-name-qualifier
with aconstant-expression
that reflects the global namespace, the component names are the same as for::
. Theconstant-expression
of asplice-name-qualifier
shall be a reflection of either atype-name
,namespace-name
, or the global namespace.
Extend 7.5.4.3 [expr.prim.id.qual]/3 to also cover splices:
3 The
nested-name-specifier
::
nominates the global namespace. Anested-name-specifier
with acomputed-type-specifier
nominates the type denoted by thecomputed-type-specifier
, which shall be a class or enumeration type. Anested-name-specifier
with asplice-name-qualifier
nominates the entity reflected by theconstant-expression
of thesplice-name-qualifier
. If a nested-name-specifier N is declarative and has a simple-template-id with a template argument list A that involves a template parameter, let T be the template nominated by N without A. T shall be a class template.…
Add a new subsection of 7.5 [expr.prim] following 7.5.7 [expr.prim.req]
Expression Splicing [expr.prim.splice]
1 For a
primary-expression
of the form[: constant-expression :]
ortemplate[: constant-expression :] < template-argument-listopt >
theconstant-expression
shall be a converted constant expression (7.7 [expr.const]) of typestd::meta::info
.2 For a
splice-expression
of the form[: constant-expression :]
where the convertedconstant-expression
evaluates to a reflection for an object, a function which is not a constructor or destructor, a non-static data member, or an enumerator, or a structured binding, the expression is an lvalue denoting the reflected entity. If the convertedconstant-expression
evaluates to a reflection for a variable or a structured binding, the expression is an lvalue denoting the object designated by the reflected entity. [ Note 1: Access checking of class members occurs during name lookup, and therefore does not pertain to splicing. — end note ]3 Otherwise, for a
splice-expression
of the form[: constant-expression :]
the convertedconstant-expression
shall evaluate to a reflection of a value, and the expression shall be a prvalue whose evaluation computes the reflected value.
Add a production to
postfix-expression
for
splices in member access expressions:
[1]{.pnum} Postfix expressions group left-to-right. postfix-expression: ... postfix-expression . templateopt id-expression+ postfix-expression . templateopt splice-expression postfix-expression -> templateopt id-expression+ postfix-expression -> templateopt splice-expression
Modify paragraph 1 to account for splices in member access expressions:
1 A postfix expression followed by a dot
.
or an arrow->
, optionally followed by the keyword template, and then followed by an id-expression or a splice-expression, is a postfix expression. [ Note 1: If the keywordtemplate
is used, the following unqualified name is considered to refer to a template ([temp.names]). If asimple-template-id
results and is followed by a::
, the id-expression or splice-expression is a qualified-id. — end note ]
Modify paragraph 2 to account for splices in member access expressions:
2 For the first option, if the dot is followed by an
id-expression
namesorsplice-expression
naming a static member or an enumerator, the first expression is a discarded-value expression ([expr.context]); if theid-expression
orsplice-expression
names a non-static data member, the first expression shall be a glvalue. For the second option (arrow), the first expression shall be a prvalue having pointer type. The expression E1->E2 is converted to the equivalent form (*(E1)).E2; the remainder of [expr.ref] will address only the first option (dot).
Modify paragraph 3 to account for splices in member access expressions:
3 The postfix expression before the dot is evaluated the result of that evaluation, together with the
id-expression
orsplice-expression
, determines the result of the entire postfix expression.
Modify paragraph 4 to account for splices in member access expressions:
4 Abbreviating
postfix-expression
.id-expression
postfix-expression.EXPR
, whereEXPR
is theid-expression
orsplice-expression
following the dot, asE1.E2
,E1
is called theobject expression
. If the object expression is of scalar type,E2
shall name the pseudo-destructor of that same type (ignoring cv-qualifications) andE1.E2
is a prvalue of type “function of () returningvoid
”.
Change 7.6.2.1 [expr.unary.general] paragraph 1 to add productions for the new operator:
1 Expressions with unary operators group right-to-left.
unary-expression: ... delete-expression+ reflect-expression + reflect-expression: + ^ :: + ^ namespace-name + ^ nested-name-specifieropt template-name + ^ nested-name-specifieropt concept-name + ^ type-id + ^ id-expression
Add a new subsection of 7.6.2 [expr.unary] following 7.6.2.9 [expr.delete]
The Reflection Operator [expr.reflect]
1 The unary
^
operator (called the reflection operator) produces a prvalue — called a reflection — whose type is the reflection type (i.e.,std::meta::info
). That reflection represents its operand.2 Every value of type
std::meta::info
is either a reflection of some entity (or description thereof) or a null reflection value.3 A reflect-expression is parsed as the longest possible sequence of tokens that could syntactically form a reflect-expression.
[ Example 1:— end example ]static_assert(is_type(^int())); // ^ applies to the type-id "int()" template<bool> struct X {}; bool operator<(std::meta::info, X<false>); consteval void g(std::meta::info r, X<false> xv) { if (r == ^int && true); // error: ^ applies to the type-id "int&&" if (r == ^int & true); // error: ^ applies to the type-id "int&" if (r == (^int) && true); // OK if (^X < xv); // error: < starts template argument list if ((^X) < xv); // OK }
5 When applied to
::
, the reflection operator produces a reflection for the global namespace. When applied to anamespace-name
, the reflection operator produces a reflection for the indicated namespace or namespace alias.6 When applied to a
template-name
, the reflection operator produces a reflection for the indicated template.7 When applied to a
concept-name
, the reflection operator produces a reflection for the indicated concept.8 When applied to a
type-id
, the reflection operator produces a reflection for the indicated type or type alias.9 When applied to an lvalue
id-expression
(7.5.4 [expr.prim.id]), the reflection operator produces a reflection of the variable, function, enumerator constant, or non-static member designated by the operand. Theid-expression
is not evaluated.
- (9.1) If this
id-expression
names an overload setS
, and if the assignment ofS
to an invented variable of typeconst auto
(9.2.9.7.2 [dcl.type.auto.deduct]) would select a unique candidate functionF
fromS
, the result is a reflection ofF
. Otherwise, the expression^S
is ill-formed.10 When applied to a prvalue
id-expression
, the reflection operator produces a reflection of the value computed by the operand [ Note 1: Anid-expression
naming a non-type template parameter of non-class and non-reference type is a prvalue. — end note ][ Example 2:— end example ]template <typename T> void fn() requires (^T != ^int); template <typename T> void fn() requires (^T == ^int); template <typename T> void fn() requires (sizeof(T) == sizeof(int)); constexpr auto R = ^fn<char>; // OK constexpr auto S = ^fn<int>; // error: cannot reflect an overload set constexpr auto r = ^std::vector; // OK
Extend 7.6.10 [expr.eq]/2 to also handle `std::meta::info:
2 The converted operands shall have arithmetic, enumeration, pointer, or pointer-to-member type, or
typetypesstd::meta::info
orstd::nullptr_t
. The operators==
and!=
both yieldtrue
orfalse
, i.e., a result of typebool
. In each case below, the operands shall have the same type after the specified conversions have been applied.
Add a new paragraph between 7.6.10 [expr.eq]/5 and /6:
5 Two operands of type
std::nullptr_t
or one operand of typestd::nullptr_t
and the other a null pointer constant compare equal.* If both operands are of type
std::meta::info
, comparison is defined as follows:
- (*.1) If both operands are null reflection values, then they compare equal.
- (*.2) Otherwise, if one operand is a null reflection value, then they compare unequal.
- (*.3) Otherwise, if one operand is a reflection of a namespace alias, alias template, or type alias and the other operand is not a reflection of the same kind of alias, they compare unequal. [ Note 1: A reflection of a type and a reflection of an alias to that same type do not compare equal. — end note ]
- (*.4) Otherwise, if both operands are reflections of a namespace alias, alias template, or type alias, then they compare equal if their reflected aliases share the same name, are declared within the same enclosing scope, and alias the same underlying entity.
- (*.5) Otherwise, if neither operand is a reflection of a value, then they compare equal if they are reflections of the same entity.
- (*.6) Otherwise, if one operand is a reflection of a value and the other is not, then they compare unequal.
- (*.7) Otherwise, if both operands are reflections of values, then they compare equal if and only if the reflected values are template-argument-equivalent (13.6 [temp.type]).
- (*.8) Otherwise the result is unspecified.
6 If two operands compare equal, the result is
true
for the==
operator andfalse
for the!=
operator. If two operands compare unequal, the result isfalse
for the==
operator andtrue
for the!=
operator. Otherwise, the result of each of the operators is unspecified.
Add a new paragraph after the definition of manifestly constant-evaluated 7.7 [expr.const]/20:
21 An expression or conversion is plainly constant-evaluated if it is:
(21.1) a
constant-expression
, or(21.2) the condition of a constexpr if statement (8.5.2 [stmt.if]),
(21.3) the initializer of a
constexpr
(9.2.6 [dcl.constexpr]) orconstinit
(9.2.7 [dcl.constinit]) variable, or(21.4) an immediate invocation, unless it
- (21.4.1) results from the substitution of template parameters in a concept-id (13.3 [temp.names]), a
requires-expression
(7.5.7 [expr.prim.req]), or during template argument deduction (13.10.3 [temp.deduct]), or- (21.4.2) is a manifestly constant-evaluated initializer of a variable that is neither
constexpr
(9.2.6 [dcl.constexpr]) norconstinit
(9.2.7 [dcl.constinit]).
typedef
specifierIntroduce the term “type alias” to 9.2.4 [dcl.typedef]:
1 […] A name declared with the
typedef
specifier becomes a typedef-name. A typedef-name names the type associated with the identifier ([dcl.decl]) or simple-template-id ([temp.pre]); a typedef-name is thus a synonym for another type. A typedef-name does not introduce a new type the way a class declaration ([class.name]) or enum declaration ([dcl.enum]) does.2 A typedef-name can also be introduced by an alias-declaration. The identifier following the using keyword is not looked up; it becomes a typedef-name and the optional attribute-specifier-seq following the identifier appertains to that typedef-name. Such a typedef-name has the same semantics as if it were introduced by the typedef specifier. In particular, it does not define a new type.
* A type alias is either a name declared with the
typedef
specifier or a name introduced by an alias-declaration.
Extend the grammar for
computed-type-specifier
as
follows:
computed-type-specifier: decltype-specifier pack-index-specifier+ splice-type-specifier + splice-enum-name: + [: constant-expression :] + using-enum-declarator: nested-name-specifieropt identifier nested-name-specifieropt simple-template-id+ splice-enum-name
Add a new subsection of 9.2.9 [dcl.type] following 9.2.9.8 [dcl.type.class.deduct].
+ splice-type-specifier + typename [: constant-expression :] + [: constant-expression :]
1 The
constant-expression
shall be a converted constant expression (7.7 [expr.const]) of typestd::meta::info
.2 The form
[: constant-expression :]
shall only be parsed as asplice-type-specifier
within a type-only context (13.8.1 [temp.res.general]).3 The
constant-expression
shall evaluate to a reflection of a type, and the type designated by thesplice-type-specifier
is the same as the type reflected by theconstant-expression
.
Change paragraphs 6-9 of 9.4.1 [dcl.init.general] [ Editor's note: No changes are necessary for value-initialization, which already forwards to zero-initialization for scalar types ]:
6 To zero-initialize an object or reference of type
T
means:
- (6.0) if
T
isstd::meta::info
, the object is initialied to a null reflection value;- (6.1) if
T
is a scalar type ([basic.types.general]), the object is initialized to the value obtained by converting the integer literal0
(zero) toT
;- (6.2) […]
7 To default-initialize an object of type
T
means:
- (7.1) If
T
is a (possibly cv-qualified) class type ([class]), […]- (7.2) If T is an array type, […]
- (7.*) If
T
isstd::meta::info
, the object is zero-initialized.- (7.3) Otherwise, no initialization is performed.
8 A class type
T
is const-default-constructible ifT
isstd::meta::info
, default-initialization ofT
would invoke a user-provided constructor of T (not inherited from a base class), or if
- (8.1) […]
9 To value-initialize an object of type T means: […]
Add a bullet to paragraph 9 of 9.3.4.6 [dcl.fct] to allow for reflections of abominable function types:
9 A function type with a cv-qualifier-seq or a ref-qualifier (including a type named by typedef-name ([dcl.typedef], [temp.param])) shall appear only as:
- (9.1) the function type for a non-static member function,
- (9.2) …
- (9.5) the type-id of a template-argument for a type-parameter ([temp.arg.type])
.,
- (9.6) the operand of a reflect-expression ([expr.reflect]).
Change paragraph 2 of 9.5.3 [dcl.fct.def.delete] to allow for reflections of deleted functions:
2 A program that refers to a deleted function implicitly or explicitly, other than to declare it or to use as the operand of the reflection operator, is ill-formed.
using enum
declarationExtend the grammar for
using-enum-declarator
as
follows:
using-enum-declaration: using enum using-enum-declarator ; + splice-enum-name: + [: constant-expression :] + using-enum-declarator: nested-name-specifieropt identifier nested-name-specifieropt simple-template-id+ splice-enum-name
Modify paragraph 1 of 9.7.2 [enum.udecl] as follows:
1 A
using-enum-declarator
not consisting of asplice-enum-name
names the set of declarations found by lookup (6.5.3 [basic.lookup.unqual], 6.5.5 [basic.lookup.qual]) for theusing-enum-declarator
. Ausing-enum-declarator
containing asplice-enum-name
names the entity reflected by theconstant-expression
. Theusing-enum-declarator
shall designate a non-dependent type with a reachableenum-specifier
.
Modify the grammar for
using-directive
as
follows:
+ splice-namespace-name: + [: constant-expression :] + + namespace-declarator: + nested-name-specifieropt namespace-name + splice-namespace-name + using-directive:- attribute-specifier-seqopt using namespace $nested-name-specifieropt namespace-name + attribute-specifier-seqopt using namespace namespace-declarator
Add the following to paragraph 1 of 9.8.4 [namespace.udir], prior to the note:
1 A
using-directive
shall not appear in class scope, but may appear in namespace scope or in block scope. Anamespace-declarator
not consisting of asplice-namespace-name
nominates the namespace found by lookup (6.5.3 [basic.lookup.unqual], 6.5.5 [basic.lookup.qual]) and shall not contain a dependentnested-name-specifier
. Anamespace-declarator
consisting of asplice-namespace-name
shall contain a non-dependentconstant-expression
that reflects a namespace or namespace alias, and nominates the entity reflected by theconstant-expression
.
Add a production to the grammar for
attribute-specifier
as
follows:
attribute-specifier: [ [ attribute-using-prefixopt attribute-list ] ]+ [ [ using attribute-namespace :] ] alignment-specifier
and update the grammar for balanced token as follows:
balanced-token : ( balanced-token-seqopt ) [ balanced-token-seqopt ] { balanced-token-seqopt }- any token other than a parenthesis, a bracket, or a brace + [: balanced-token-seqopt :] + any token other than (, ), [, ], {, }, [:, or :]
Change a sentence in paragraph 4 of 9.12.1 [dcl.attr.grammar] as follows:
4 […] An
attribute-specifier
that contains noattribute
s and noalignment-specifier
has no effect. [ Note 1: That includes anattribute-specifier
of the form[ [ using attribute-namespace :] ]
which is thus equivalent to replacing the:]
token by the two-token sequence:
]
. — end note ] …
Add built-in operator candidates for std::meta::info
to 12.5 [over.built]:
16 For every
T
, whereT
is a pointer-to-member type,std::meta::info
, orstd::nullptr_t
, there exist candidate operator functions of the formbool operator==(T, T); bool operator!=(T, T);
Extend the last sentence of paragraph 4 to disallow splicing concepts in template parameter declarations.
4 … The concept designated by a type-constraint shall be a type concept ([temp.concept]) that does not consist of a
splice-template-name
.
Modify the grammars for
template-id
and
template-argument
as
follows:
+ splice-template-name: + template [: constant-expression :] + + splice-template-argument: + [: constant-expression :] + template-name: identifier+ splice-template-name template-argument: constant-expression type-id id-expression braced-init-list+ splice-template-argument
Extend paragraph 1 to cover template splicers:
The component name of a
simple-template-id
,template-id
, ortemplate-name
is the first name in it. If thetemplate-name
is asplice-template-name
, the convertedconstant-expression
shall evaluate to a reflection for a concept, variable template, class template, alias template, or function template which is not a constructor template or destructor template; thesplice-template-name
names the entity reflected by theconstant-expression
.
Add a paragraph after paragraph 3 of 13.3 [temp.names]:
* A
<
is also interpreted as the delimiter of atemplate-argument-list
if it follows atemplate-name
consisting of asplice-template-name
.
Adjust paragraph 3 of [temp.arg.general] to not apply to splice template arguments:
3 In a
template-argument
which does not contain asplice-template-argument
, an ambiguity between atype-id
and an expression is resolved to atype-id
, regardless of the form of the correspondingtemplate-parameter
. In atemplate-argument
containing asplice-template-argument
, an ambiguity between asplice-template-argument
and an expression is resolved to asplice-template-argument
.
Extend 13.4.2 [temp.arg.type]/1 to cover splice template arguments:
1 A
template-argument
for atemplate-parameter
which is a type shall either be atype-id
or asplice-template-argument
. Atemplate-argument
having asplice-template-argument
for such atemplate-parameter
is treated as if it were atype-id
nominating the type reflected by theconstant-expression
of thesplice-template-argument
.
Extend 13.4.3 [temp.arg.nontype]/2 to cover splice template arguments:
2 The value of a non-type
template-parameter
P of (possibly deduced) typeT
is determined from its template argument A as follows. IfT
is not a class type and A isnotneither abraced-init-list
nor asplice-template-argument
, A shall be a converted constant expression ([expr.const]) of typeT
; the value of P is A (as converted).
Extend 13.4.4 [temp.arg.template]/1 to cover splice template arguments:
1 A
template-argument
for a templatetemplate-parameter
shall be the name of a class template or an alias template, expressed asid-expression
, or asplice-template-argument
. Atemplate-argument
for a templatetemplate-parameter
having asplice-template-argument
is treated as anid-expression
nominating the class template or alias template reflected by theconstant-expression
of thesplice-template-argument
.
Extend template-argument-equivalent to handle std::meta::info
:
2 Two values are template-argument-equivalent if they are of the same type and
- (2.1) they are of integral type and their values are the same, or
- (2.2) they are of floating-point type and their values are identical, or
- (2.3) they are of type
std::nullptr_t
, or- (2.*) they are of type
std::meta::info
and they compare equal, or- (2.4) they are of enumeration type and their values are the same, or
- (2.5) […]
Extend the grammar of
concept-name
to allow for
splicing reflections of concepts:
concept-name: identifier+ splice-template-name
Modify paragraph 2 to account for splicing reflections of concepts:
A
concept-definition
declares a concept. Itsconcept-name
shall consist of anidentifier
, and theidentifier
becomes a concept-name referring to that concept within its scope. The optional attribute-specifier-seq appertains to the concept.
Add to the list of never-type-dependent expression forms in 13.8.3.3 [temp.dep.expr]/4:
literal sizeof unary-expression sizeof ( type-id ) sizeof ... ( identifier ) alignof ( type-id ) typeid ( expression ) typeid ( type-id ) ::opt delete cast-expression ::opt delete [ ] cast-expression throw assignment-expressionopt noexcept ( expression ) requires-expression+ reflect-expression
Add a new paragraph at the end of 13.8.3.3 [temp.dep.expr]:
9 A
primary-expression
of the form[: constant-expression :]
ortemplate[: constant-expression :] < template-argument-listopt >
is type-dependent if theconstant-expression
is value-dependent or if the optionaltemplate-argument-list
contains a value-dependent nontype or template argument, or a dependent type argument.
Add at the end of 13.8.3.4 [temp.dep.constexpr]/2 (before the note):
2 An id-expression is value-dependent if:
- (2.1) […]
Expressions of the following form are value-dependent if the unary-expression or expression is type-dependent or the type-id is dependent:
sizeof unary-expression sizeof ( type-id ) typeid ( expression ) typeid ( type-id ) alignof ( type-id ) noexcept ( expression )
A
reflect-expression
is value dependent if the operand of the reflection operator is a type-dependent or value-dependent expression or if that operand is a dependenttype-id
, a dependentnamespace-name
, or a dependenttemplate-name
.
Add a new paragraph after 13.8.3.4 [temp.dep.constexpr]/4:
6 A
primary-expression
of the form[: constant-expression :]
ortemplate[: constant-expression :] < template-argument-listopt >
is value-dependent if theconstant-expression
is value-dependent or if the optionaltemplate-argument-list
contains a value-dependent nontype or template argument, or a dependent type argument.
Insert before paragraph 7:
6 Let F denote a standard library function ([global.functions]), a standard library static member function, or an instantiation of a standard library function template. Unless F is designated an addressable function, the behavior of a C++ program is unspecified (possibly ill-formed) if it explicitly or implicitly attempts to form a pointer to F. […]
7pre Let F denote a standard library function, member function, or function template. If F does not designate an addressable function, it is unspecified if or how a reflection value designating the associated entity can be formed. [ Note 1: E.g.,
std::meta::members_of
might not produce reflections of standard functions that an implementation handles through an extra-linguistic mechanism. — end note ]7 A translation unit shall not declare namespace std to be an inline namespace ([namespace.def]).
<type_traits>
synopsisAdd a new primary type category type trait:
Header
<type_traits>
synopsis…
// [meta.unary.cat], primary type categories template<class T> struct is_void; ... template<class T> struct is_function;+ template<class T> struct is_reflection; // [meta.unary.cat], primary type categories template<class T> constexpr bool is_void_v = is_void<T>::value; ... template<class T> constexpr bool is_reflection_v = is_function<T>::value;+ template<class T> + constexpr bool is_reflection_v = is_function<T>::value;
Add the is_reflection
primary
type category to the table in paragraph 3:
Template | Condition | Comments |
---|---|---|
|
T is
void
|
|
… | … | … |
|
|
|
<meta>
synopsisAdd a new subsection in 21 [meta] after 21.3 [type.traits]:
Header
<meta>
synopsis#include <span> #include <string_view> #include <vector> namespace std::meta { using info = decltype(^::); // [meta.reflection.names], reflection names and locations consteval string_view name_of(info r); consteval string_view qualified_name_of(info r); consteval string_view display_name_of(info r); consteval u8string_view u8name_of(info r); consteval u8string_view u8qualified_name_of(info r); consteval u8string_view u8display_name_of(info r); consteval source_location source_location_of(info r); // [meta.reflection.queries], reflection queries consteval bool is_public(info r); consteval bool is_protected(info r); consteval bool is_private(info r); consteval bool is_virtual(info r); consteval bool is_pure_virtual(info r); consteval bool is_override(info r); consteval bool is_deleted(info r); consteval bool is_defaulted(info r); consteval bool is_explicit(info r); consteval bool is_noexcept(info r); consteval bool is_bit_field(info r); consteval bool is_const(info r); consteval bool is_volatile(info r); consteval bool is_final(info r); consteval bool has_static_storage_duration(info r); consteval bool has_internal_linkage(info r); consteval bool has_module_linkage(info r); consteval bool has_external_linkage(info r); consteval bool has_linkage(info r); consteval bool is_namespace(info r); consteval bool is_function(info r); consteval bool is_variable(info r); consteval bool is_type(info r); consteval bool is_alias(info r); consteval bool is_incomplete_type(info r); consteval bool is_template(info r); consteval bool is_function_template(info r); consteval bool is_variable_template(info r); consteval bool is_class_template(info r); consteval bool is_alias_template(info r); consteval bool is_concept(info r); consteval bool is_value(info r); consteval bool is_object(info r); consteval bool is_structured_binding(info r); consteval bool has_template_arguments(info r); consteval bool is_class_member(info entity); consteval bool is_namespace_member(info entity); consteval bool is_nonstatic_data_member(info r); consteval bool is_static_member(info r); consteval bool is_base(info r); consteval bool is_constructor(info r); consteval bool is_destructor(info r); consteval bool is_special_member(info r); consteval bool is_user_provided(info r); consteval info type_of(info r); consteval info object_of(info r); consteval info value_of(info r); consteval info parent_of(info r); consteval info dealias(info r); consteval info template_of(info r); consteval vector<info> template_arguments_of(info r); // [meta.reflection.member.queries], reflection member queries template<class... Fs> consteval vector<info> members_of(info type, Fs... filters); template<class... Fs> consteval vector<info> bases_of(info type, Fs... filters); consteval vector<info> static_data_members_of(info type); consteval vector<info> nonstatic_data_members_of(info type); consteval vector<info> subobjects_of(info type); consteval vector<info> enumerators_of(info type_enum); // [meta.reflection.member.access], reflection member access queries consteval info access_context(); struct access_pair { consteval access_pair(info target, info from = access_context()); }; consteval bool is_accessible(access_pair p); consteval bool is_accessible(info r, info from); template <typename... Preds> consteval vector<info> accessible_members_of(access_pair p, Preds... preds); template <typename... Preds> consteval vector<info> accessible_members_of(info target, info from, Preds... preds); template <typename... Preds> consteval vector<info> accessible_bases_of(access_pair p, Preds... preds); template <typename... Preds> consteval vector<info> accessible_bases_of(info target, info from, Preds... preds); consteval vector<info> accessible_nonstatic_data_members_of(access_pair p); consteval vector<info> accessible_nonstatic_data_members_of(info target, info from); consteval vector<info> accessible_static_data_members_of(access_pair p); consteval vector<info> accessible_static_data_members_of(info target, info from); consteval vector<info> accessible_subobjects_of(access_pair p); consteval vector<info> accessible_subobjects_of(info target, info from); // [meta.reflection.layout], reflection layout queries consteval size_t offset_of(info entity); consteval size_t size_of(info entity); consteval size_t alignment_of(info entity); consteval size_t bit_offset_of(info entity); consteval size_t bit_size_of(info entity); // [meta.reflection.extract], value extraction template <typename T> consteval T extract(info); // [meta.reflection.substitute], reflection substitution template <reflection_range R = span<info const>> consteval bool can_substitute(info templ, R&& arguments); template <reflection_range R = span<info const>> consteval info substitute(info templ, R&& arguments); consteval bool test_trait(info templ, info type); template <reflection_range R = span<info const>> consteval bool test_trait(info templ, R&& arguments); // [meta.reflection.result], expression result reflection template <class R> concept reflection_range = see below; template <typename T> consteval info reflect_value(T value); template <typename T> consteval info reflect_object(T& object); template <typename T> consteval info reflect_function(T& fn); template <reflection_range R = span<info const>> consteval info reflect_invoke(info target, R&& args); template <reflection_range R1 = span<info const>, reflection_range R2 = span<info const>> consteval info reflect_invoke(info target, R1&& tmpl_args, R2&& args); // [meta.reflection.define_class], class definition generation struct data_member_options_t { struct name_type { template <typename T> requires constructible_from<u8string, T> consteval name_type(T &&); template <typename T> requires constructible_from<string, T> consteval name_type(T &&); }; optional<name_type> name; optional<int> alignment; optional<int> width; bool no_unique_address = false; }; consteval info data_member_spec(info type, data_member_options_t options = {}); template <reflection_range R = span<info const>> consteval info define_class(info type_class, R&&); // [meta.reflection.unary.cat], primary type categories consteval bool type_is_void(info type); consteval bool type_is_null_pointer(info type); consteval bool type_is_integral(info type); consteval bool type_is_floating_point(info type); consteval bool type_is_array(info type); consteval bool type_is_pointer(info type); consteval bool type_is_lvalue_reference(info type); consteval bool type_is_rvalue_reference(info type); consteval bool type_is_member_object_pointer(info type); consteval bool type_is_member_function_pointer(info type); consteval bool type_is_enum(info type); consteval bool type_is_union(info type); consteval bool type_is_class(info type); consteval bool type_is_function(info type); consteval bool type_is_reflection(info type); // [meta.reflection.unary.comp], composite type categories consteval bool type_is_reference(info type); consteval bool type_is_arithmetic(info type); consteval bool type_is_fundamental(info type); consteval bool type_is_object(info type); consteval bool type_is_scalar(info type); consteval bool type_is_compound(info type); consteval bool type_is_member_pointer(info type); // [meta.reflection unary.prop], type properties consteval bool type_is_const(info type); consteval bool type_is_volatile(info type); consteval bool type_is_trivial(info type); consteval bool type_is_trivially_copyable(info type); consteval bool type_is_standard_layout(info type); consteval bool type_is_empty(info type); consteval bool type_is_polymorphic(info type); consteval bool type_is_abstract(info type); consteval bool type_is_final(info type); consteval bool type_is_aggregate(info type); consteval bool type_is_signed(info type); consteval bool type_is_unsigned(info type); consteval bool type_is_bounded_array(info type); consteval bool type_is_unbounded_array(info type); consteval bool type_is_scoped_enum(info type); template <reflection_range R = span<info const>> consteval bool type_is_constructible(info type, R&& type_args); consteval bool type_is_default_constructible(info type); consteval bool type_is_copy_constructible(info type); consteval bool type_is_move_constructible(info type); consteval bool type_is_assignable(info type_dst, info type_src); consteval bool type_is_copy_assignable(info type); consteval bool type_is_move_assignable(info type); consteval bool type_is_swappable_with(info type_dst, info type_src); consteval bool type_is_swappable(info type); consteval bool type_is_destructible(info type); template <reflection_range R = span<info const>> consteval bool type_is_trivially_constructible(info type, R&& type_args); consteval bool type_is_trivially_default_constructible(info type); consteval bool type_is_trivially_copy_constructible(info type); consteval bool type_is_trivially_move_constructible(info type); consteval bool type_is_trivially_assignable(info type_dst, info type_src); consteval bool type_is_trivially_copy_assignable(info type); consteval bool type_is_trivially_move_assignable(info type); consteval bool type_is_trivially_destructible(info type); template <reflection_range R = span<info const>> consteval bool type_is_nothrow_constructible(info type, R&& type_args); consteval bool type_is_nothrow_default_constructible(info type); consteval bool type_is_nothrow_copy_constructible(info type); consteval bool type_is_nothrow_move_constructible(info type); consteval bool type_is_nothrow_assignable(info type_dst, info type_src); consteval bool type_is_nothrow_copy_assignable(info type); consteval bool type_is_nothrow_move_assignable(info type); consteval bool type_is_nothrow_swappable_with(info type_dst, info type_src); consteval bool type_is_nothrow_swappable(info type); consteval bool type_is_nothrow_destructible(info type); consteval bool type_is_implicit_lifetime(info type); consteval bool type_has_virtual_destructor(info type); consteval bool type_has_unique_object_representations(info type); consteval bool type_reference_constructs_from_temporary(info type_dst, info type_src); consteval bool type_reference_converts_from_temporary(info type_dst, info type_src); // [meta.reflection.unary.prop.query], type property queries consteval size_t type_alignment_of(info type); consteval size_t type_rank(info type); consteval size_t type_extent(info type, unsigned i = 0); // [meta.reflection.rel], type relations consteval bool type_is_same(info type1, info type2); consteval bool type_is_base_of(info type_base, info type_derived); consteval bool type_is_convertible(info type_src, info type_dst); consteval bool type_is_nothrow_convertible(info type_src, info type_dst); consteval bool type_is_layout_compatible(info type1, info type2); consteval bool type_is_pointer_interconvertible_base_of(info type_base, info type_derived); template <reflection_range R = span<info const>> consteval bool type_is_invocable(info type, R&& type_args); template <reflection_range R = span<info const>> consteval bool type_is_invocable_r(info type_result, info type, R&& type_args); template <reflection_range R = span<info const>> consteval bool type_is_nothrow_invocable(info type, R&& type_args); template <reflection_range R = span<info const>> consteval bool type_is_nothrow_invocable_r(info type_result, info type, R&& type_args); // [meta.reflection.trans.cv], const-volatile modifications consteval info type_remove_const(info type); consteval info type_remove_volatile(info type); consteval info type_remove_cv(info type); consteval info type_add_const(info type); consteval info type_add_volatile(info type); consteval info type_add_cv(info type); // [meta.reflection.trans.ref], reference modifications consteval info type_remove_reference(info type); consteval info type_add_lvalue_reference(info type); consteval info type_add_rvalue_reference(info type); // [meta.reflection.trans.sign], sign modifications consteval info type_make_signed(info type); consteval info type_make_unsigned(info type); // [meta.reflection.trans.arr], array modifications consteval info type_remove_extent(info type); consteval info type_remove_all_extents(info type); // [meta.reflection.trans.ptr], pointer modifications consteval info type_remove_pointer(info type); consteval info type_add_pointer(info type); // [meta.reflection.trans.other], other transformations consteval info type_remove_cvref(info type); consteval info type_decay(info type); template <reflection_range R = span<info const>> consteval info type_common_type(R&& type_args); template <reflection_range R = span<info const>> consteval info type_common_reference(R&& type_args); consteval info type_underlying_type(info type); template <reflection_range R = span<info const>> `consteval info type_invoke_result(info type, R&& type_args); consteval info type_unwrap_reference(info type); consteval info type_unwrap_ref_decay(info type); }
consteval string_view name_of(info r); consteval u8string_view u8name_of(info r);
1 Mandates: If returning
string_view
, the unqualified name is representable using the ordinary string literal encoding.2 Returns: If
r
designates a declared entityX
, then the unqualified name ofX
. Otherwise, an emptystring_view
oru8string_view
, respectively.consteval string_view qualified_name_of(info r); consteval u8string_view u8qualified_name_of(info r);
3 Mandates: If returning
string_view
, the qualified name is representable using the ordinary string literal encoding.4 Returns: If
r
designates a declared entityX
, then the qualified name ofX
. Otherwise, an emptystring_view
oru8string_view
, respectively.consteval string_view display_name_of(info r); consteval u8string_view u8display_name_of(info r);
5 Mandates: If returning
string_view
, the implementation-defined name is representable using the ordinary string literal encoding.6 Returns: An implementation-defined
string_view
oru8string_view
, respectively, suitable for identifying the reflected construct.consteval source_location source_location_of(info r);
7 Returns: An implementation-defined
source_location
corresponding to the reflected construct.
consteval bool is_public(info r); consteval bool is_protected(info r); consteval bool is_private(info r);
1 Returns:
true
ifr
designates a class member or base class that is public, protected, or private, respectively. Otherwise,false
.consteval bool is_virtual(info r);
2 Returns:
true
ifr
designates a either a virtual member function or a virtual base class. Otherwise,false
.consteval bool is_pure_virtual(info r); consteval bool is_override(info r);
3 Returns:
true
ifr
designates a member function that is pure virtual or overrides another member function, respectively. Otherwise,false
.consteval bool is_deleted(info r);
4 Returns:
true
ifr
designates a function that is defined as deleted. Otherwise,false
.consteval bool is_defaulted(info r);
5 Returns:
true
ifr
designates a function that is defined as defaulted. Otherwise,false
.consteval bool is_explicit(info r);
6 Returns:
true
ifr
designates a member function that is declared explicit. Otherwise,false
.consteval bool is_noexcept(info r);
7 Returns:
true
ifr
designates anoexcept
function type, a pointer tonoexcept
function or member function type, a closure type of a non-generic lambda whose call operator is declarednoexcept
, a value of any of the previously mentioned types, or a function that is declarednoexcept
. Otherwise,false
.consteval bool is_bit_field(info r);
8 Returns:
true
ifr
designates a bit-field. Otherwise,false
.consteval bool is_const(info r); consteval bool is_volatile(info r);
9 Returns:
true
ifr
designates a const or volatile type (respectively), a const- or volatile-qualified function type (respectively), or an object, variable, non-static data member, or function with such a type. Otherwise,false
.consteval bool is_final(info r);
10 Returns:
true
ifr
designates a final class or a final member function. Otherwise,false
.consteval bool has_static_storage_duration(info r);
11 Returns:
true
ifr
designates an object or variable that has static storage duration. Otherwise,false
.consteval bool has_internal_linkage(info r); consteval bool has_module_linkage(info r); consteval bool has_external_linkage(info r); consteval bool has_linkage(info r);
12 Returns:
true
ifr
designates an entity that has internal linkage, module linkage, external linkage, or any linkage, respectively ([basic.link]). Otherwise,false
.consteval bool is_namespace(info r);
13 Returns:
true
ifr
designates a namespace or namespace alias. Otherwise,false
.consteval bool is_function(info r);
14 Returns:
true
ifr
designates a function or member function. Otherwise,false
.consteval bool is_variable(info r);
15 Returns:
true
ifr
designates a variable. Otherwise,false
.consteval bool is_type(info r);
16 Returns:
true
ifr
designates a type or a type alias. Otherwise,false
.consteval bool is_alias(info r);
17 Returns:
true
ifr
designates a type alias, alias template, or namespace alias. Otherwise,false
.consteval bool is_incomplete_type(info r);
18 Mandates:
r
is a reflection designating a type.19 Effects: If
dealias(r)
designates a class template specialization with a reachable definition, the specialization is instantiated.20 Returns:
true
if the type designated bydealias(r)
is an incomplete type ([basic.types]). Otherwise,false
.consteval bool is_template(info r);
21 Returns:
true
ifr
designates a function template, class template, variable template, or alias template. Otherwise,false
.22 [ Note 1: A template specialization is not a template.
is_template(^std::vector)
istrue
butis_template(^std::vector<int>)
isfalse
. — end note ]consteval bool is_function_template(info r); consteval bool is_variable_template(info r); consteval bool is_class_template(info r); consteval bool is_alias_template(info r); consteval bool is_concept(info r); consteval bool is_structured_binding(info r); consteval bool is_value(info r);
23 Returns:
true
ifr
designates a function template, class template, variable template, alias template, concept, structured binding, or value respectively. Otherwise,false
.consteval bool is_object(info r);
24 Returns:
true
ifr
designates an object. Otherwise,false
.consteval bool has_template_arguments(info r);
25 Returns:
true
ifr
designates an instantiation of a function template, variable template, class template, or an alias template. Otherwise,false
.consteval bool is_class_member(info r); consteval bool is_namespace_member(info r); consteval bool is_nonstatic_data_member(info r); consteval bool is_static_member(info r); consteval bool is_base(info r); consteval bool is_constructor(info r); consteval bool is_destructor(info r); consteval bool is_special_member(info r);
26 Returns:
true
ifr
designates a class member, namespace member, non-static data member, static member, base class member, constructor, destructor, or special member, respectively. Otherwise,false
.consteval bool is_user_provided(info r);
27 Mandates:
r
designates a function.28 Returns:
true
ifr
designates a user-provided (9.5.2 [dcl.fct.def.default]) function. Otherwise,false
.consteval info type_of(info r);
29 Mandates:
r
designates a typed entity.r
does not designate a constructor, destructor, or structured binding.30 Returns: A reflection of the type of that entity. If every declaration of that entity was declared with the same type alias (but not a template parameter substituted by a type alias), the reflection returned is for that alias. Otherwise, if some declaration of that entity was declared with an alias it is unspecified whether the reflection returned is for that alias or for the type underlying that alias. Otherwise, the reflection returned shall not be a type alias reflection.
consteval info object_of(info r);
31 Mandates:
r
is a reflection designating either an object or a variable denoting an object with static storage duration ([expr.const]).32 Returns: If
r
is a reflection of a variable, then a reflection of the object denoted by the variable. Otherwise,r
.consteval info value_of(info r);
33 Mandates:
r
is a reflection designating either an object or variable usable in constant expressions ([expr.const]), an enumerator, or a value.34 Returns: If
r
is a reflection of an objecto
, or a reflection of a variable which designates an objecto
, then a reflection of the value held byo
. The reflected value has typedealias(type_of(o))
, with the cv-qualifiers removed if this is a scalar type. Otherwise, ifr
is a reflection of an enumerator, then a reflection of the value of the enumerator. Otherwise,r
.consteval info parent_of(info r);
35 Mandates:
r
designates a member of either a class or a namespace.36 Returns: A reflection of that entity’s immediately enclosing class or namespace.
consteval info dealias(info r);
37 Returns: If
r
designates a type alias or a namespace alias, a reflection designating the underlying entity. Otherwise,r
.[ Example 1:— end example ]using X = int; using Y = X; static_assert(dealias(^int) == ^int); static_assert(dealias(^X) == ^int); static_assert(dealias(^Y) == ^int);
consteval info template_of(info r); consteval vector<info> template_arguments_of(info r);
39 Mandates:
has_template_arguments(r)
istrue
.40 Returns: A reflection of the template of
r
, and the reflections of the template arguments of the specialization designated byr
, respectively.[ Example 2:— end example ]template <class T, class U=T> struct Pair { }; template <class T> using PairPtr = Pair<T*>; static_assert(template_of(^Pair<int>) == ^Pair); static_assert(template_arguments_of(^Pair<int>).size() == 2); static_assert(template_of(^PairPtr<int>) == ^PairPtr); static_assert(template_arguments_of(^PairPtr<int>).size() == 1);
template<class... Fs> consteval vector<info> members_of(info r, Fs... filters);
1 Mandates:
r
is a reflection designating either a complete class type or a namespace and(std::predicate<Fs, info> && ...)
istrue
.2 Effects: If
dealias(r)
designates a class template specialization with a reachable definition, the specialization is instantiated.3 Returns: A
vector
containing the reflections of all the direct membersm
of the entity, excluding any structured bindings, designated byr
such that(filters(m) && ...)
istrue
. Non-static data members are indexed in the order in which they are declared, but the order of other kinds of members is unspecified. [ Note 1: Base classes are not members. — end note ]template<class... Fs> consteval vector<info> bases_of(info type, Fs... filters);
4 Mandates:
type
is a reflection designating a complete class type and(std::predicate<Fs, info> && ...)
istrue
.5 Effects: If
dealias(type)
designates a class template specialization with a reachable definition, the specialization is instantiated.6 Returns: Let
C
be the type designated bytype
. Avector
containing the reflections of all the direct base classesb
, if any, ofC
such that(filters(b) && ...)
istrue
. The base classes are indexed in the order in which they appear in the base-specifier-list ofC
.consteval vector<info> static_data_members_of(info type);
7 Effects: Equivalent to:
return members_of(type, is_variable);
consteval vector<info> nonstatic_data_members_of(info type);
8 Effects: Equivalent to:
return members_of(type, is_nonstatic_data_member);
consteval vector<info> subobjects_of(info type);
9 Mandates:
type
is a reflection designating a complete class type.10 Effects: If
dealias(type)
designates a class template specialization with a reachable definition, the specialization is instantiated.11 Returns: A
vector
containing all the reflections inbases_of(type)
followed by all the reflections innonstatic_data_members_of(type)
.consteval vector<info> enumerators_of(info type_enum);
12 Mandates:
type_enum
is a reflection designating an enumeration.13 Returns: A
vector
containing the reflections of each enumerator of the enumeration designated bytype_enum
, in the order in which they are declared.
consteval info access_context();
1 Returns: A reflection of the function, class, or namespace scope most nearly enclosing the function call.
consteval bool is_accessible(access_pair p);
2 Mandates:
p.target
is a reflection designating a member of a class.p.from
designates a function, class, or namespace.3 Returns:
true
if the class member designated byp.target
can be named within the scope ofp.from
. Otherwise,false
.consteval bool is_accessible(info target, info from);
4 Effects: Equivalent to:
return is_accessible({target, from});
template <typename... Preds> consteval vector<info> accessible_members_of(access_pair p, ... preds); Preds
5 Mandates:
p.target
is a reflection designating a complete class type.p.from
designates a function, class, or namespace.6 Effects: Equivalent to:
return members_of(p.target, [&](info r) { return is_accessible({r, p.from}); }, ...); preds
template <typename... Preds> consteval vector<info> accessible_members_of(info target, info from,... preds); Preds
7 Effects: Equivalent to:
return accessible_members_of({target, from}, preds...);
template <typename... Preds> consteval vector<info> accessible_bases_of(access_pair p, ... preds); Preds
8 Mandates:
p.target
is a reflection designating a complete class type.p.from
designates a function, class, or namespace.9 Effects: Equivalent to:
return bases_of(p.target, [&](info r) { return is_accessible({r, p.from}); }, ...); preds
template <typename... Preds> consteval vector<info> accessible_bases_of(info target, info from,... preds); Preds
10 Effects: Equivalent to:
return accessible_bases_of({target, from}, preds...);
consteval vector<info> accessible_nonstatic_data_members_of(access_pair p);
11 Effects: Equivalent to:
return accessible_members_of(p.target, ::meta::is_nonstatic_data_member, std...); preds
consteval vector<info> accessible_nonstatic_data_members_of(info target, ); info from
12 Effects: Equivalent to:
return accessible_nonstatic_data_members_of({target, from});
consteval vector<info> accessible_static_data_members_of(access_pair p);
13 Effects: Equivalent to:
return accessible_members_of(p.target, ::meta::is_static_data_member); std
consteval vector<info> accessible_static_data_members_of(info target, ); info from
14 Effects: Equivalent to:
return accessible_static_data_members_of({target, from});
consteval vector<info> accessible_subobjects_of(access_pair p);
15 Returns: A
vector
containing all the reflections inaccessible_bases_of(p)
followed by all the reflections inaccessible_nonstatic_data_members_of(p)
.consteval vector<info> accessible_subobjects_of(info target, info from);
16 Effects: Equivalent to:
return accessible_subobjects_data_members_of({target, from});
consteval size_t offset_of(info r);
1 Mandates:
r
is a reflection designating a non-static data member or non-virtual base class.2 Returns: The offset in bytes from the beginning of an object of type
parent_of(r)
to the subobject associated with the entity reflected byr
.consteval size_t size_of(info r);
3 Mandates:
r
is a reflection of a type, non-static data member, base class, object, value, or variable.4 Returns If
r
designates a typeT
, thensizeof(T)
. Otherwise,size_of(type_of(r))
.consteval size_t alignment_of(info r);
5 Mandates:
r
is a reflection designating an object, variable, type, non-static data member, or base class.6 Returns: If
r
designates a type, object, or variable, then the alignment requirement of the entity. Otherwise, ifr
designates a base class, thenalignment_of(type_of(r))
. Otherwise, the alignment requirement of the subobject associated with the reflected non-static data member within any object of typeparent_of(r)
.consteval size_t bit_offset_of(info r);
7 Mandates:
r
is a reflection designating a non-static data member or a non-virtual base class.8 Let
V
be the offset in bits from the beginning of an object of typeparent_of(r)
to the subobject associated with the entity reflected byr
.9 Returns:
V - offset_of(r)
.consteval size_t bit_size_of(info r);
10 Mandates:
r
is a reflection of a type, non-static data member, base class, object, value, or variable.11 Returns If
r
designates a type, then the size in bits of any object having the reflected type. Otherwise, ifr
reflects a non-static data member that is a bit-field, then the width of the reflected bit-field. Otherwise,bit_size_of(type_of(r))
.
template <class T> consteval T extract(info r);
1 Mandates:
r
is a reflection designating a value, object, variable, function, enumerator, or non-static data member that is not a bit-field. Ifr
reflects a value or enumerator, thenT
is not a reference type. Ifr
reflects a value or enumerator of typeU
, or ifr
reflects a variable or object of non-reference typeU
, then the cv-unqualified types ofT
andU
are the same. Ifr
reflects a variable, object, or function with typeU
, andT
is a reference type, then the cv-unqualified types ofT
andU
are the same, andT
is eitherU
or more cv-qualified thanU
. Ifr
reflects a non-static data member, or ifr
reflects a function andT
is a reference type, then the statementT v = &expr
, whereexpr
is an lvalue naming the entity designated byr
, is well-formed.2 Returns: If
r
designates a value or enumerator, then the entity reflected byr
. Otherwise, ifr
reflects an object, variable, or enumerator andT
is not a reference type, then the result of an lvalue-to-rvalue conversion applied to an expression naming the entity reflected byr
. Otherwise, ifr
reflects an object, variable, or function andT
is a reference type, then the result of an lvalue naming the entity reflected byr
. Otherwise, ifr
reflects a function or non-static data member, then a pointer value designating the entity reflected byr
.
template <class R> concept reflection_range = ::input_range<R> && ranges<ranges::range_value_t<R>, info> && same_as<remove_cvref_t<ranges::range_reference_t<R>>, info>; same_as
template <reflection_range R = span<info const>> consteval bool can_substitute(info templ, R&& arguments);
1 Mandates:
templ
designates a template.2 Let
Z
be the template designated bytempl
and letArgs...
be the sequence of entities or aliases designated by the elements ofarguments
.3 Returns:
true
ifZ<Args...>
is a valid template-id ([temp.names]). Otherwise,false
.4 Remarks: If attempting to substitute leads to a failure outside of the immediate context, the program is ill-formed.
template <reflection_range R = span<info const>> consteval info substitute(info templ, R&& arguments);
5 Mandates:
can_substitute(templ, arguments)
istrue
.6 Let
Z
be the template designated bytempl
and letArgs...
be the sequence of entities or aliases designated by the elements ofarguments
.7 Returns:
^Z<Args...>
.consteval bool test_trait(info templ, info type);
8 Effects: Equivalent to
return extract<bool>(substitute(templ, {type}));
template <reflection_range R = span<info const>> consteval bool test_trait(info templ, R&& arguments);
9 Effects: Equivalent to
return extract<bool>(substitute(templ, arguments));
template <typename T> consteval info reflect_value(T expr);
1 Mandates:
T
is a structural type that is not a reference type. Any subobject of the value computed byexpr
having reference or pointer type designates an entity that is a permitted result of a constant expression ([expr.const]).2 Returns: A reflection of the value computed by an lvalue-to-rvalue conversion applied to
expr
. The type of the reflected value is the cv-unqualified version ofT
.template <typename T> consteval info reflect_object(T& expr);
3 Mandates:
T
is not a function type.expr
designates an entity that is a permitted result of a constant expression.4 Returns: A reflection of the object referenced by
expr
.template <typename T> consteval info reflect_function(T& expr);
5 Mandates:
T
is a function type.6 Returns:
^fn
, wherefn
is the function referenced byexpr
.template <reflection_range R = span<info const>> consteval info reflect_invoke(info target, R&& args); template <reflection_range R1 = span<info const>, reflection_range R2 = span<info const>> consteval info reflect_invoke(info target, R1&& tmpl_args, R2&& args);
7 Let
F
be the entity reflected bytarget
, letArg0
be the entity reflected by the first element ofargs
(if any), letArgs...
be the sequence of entities reflected by the elements ofargs
excluding the first, and letTArgs...
be the sequence of entities or aliases designated by the elements oftmpl_args
.8 If
F
is a non-member function, a value of pointer to function type, a value of pointer to member type, or a value of closure type, then letINVOKE-EXPR
be the expressionINVOKE(F, Arg0, Args...)
. Otherwise, ifF
is a member function, then letINVOKE-EXPR
be the expressionArg0.F(Args...)
. Otherwise, ifF
is a constructor for a classC
, then letINVOKE-EXPR
be the expressionC(Arg0, Args...)
for which only the constructorF
is considered by overload resolution. Otherwise, ifF
is a non-member function template or a member function template, then letINVOKE-EXPR
be the expressionF<TArgs...>(Arg0, Args...)
orArg0.template F<TArgs...>(Args...)
respectively. Otherwise, ifF
is a constructor template, then letINVOKE-EXPR
be the expressionC(Arg0, Args...)
for which only the constructorF
is considered by overload resolution, andTArgs...
are inferred as explicit template arguments forF
.9 Mandates:
target
designates a reflection of a function, a constructor, a constructor template, a value, or a function template. Iftarget
reflects a value of typeT
, thenT
is a pointer to function type, pointer to member type, or closure type. The expressionINVOKE-EXPR
is a well-formed constant expression of structural type.10 Returns: A reflection of the result of the expression
INVOKE-EXPR
.
consteval info data_member_spec(info type, = {}); data_member_options_t options
1 Mandates:
type
designates a type. Ifoptions.name
contains a value, thestring
oru8string
value that was used to initializeoptions.name
contains a valid identifier (5.10 [lex.name]).2 Returns: A reflection of a description of the declaration of non-static data member with a type designated by
type
and optional characteristics designated byoptions
.3 Remarks: The reflection value being returned is only useful for consumption by
define_class
. No other function instd::meta
recognizes such a value.template <reflection_range R = span<info const>> consteval info define_class(info class_type, R&& mdescrs);
4 Let
d1
,d2
, …,dN
denote the reflection values of the rangemdescrs
obtained by callingdata_member_spec
withtype
valuest1
,t2
, …tN
andoption
valueso1
,o2
, …oN
respectively.5 Mandates:
class_type
designates an incomplete class type.mdescrs
is a (possibly empty) range of reflection values obtained by calls todata_member_spec
. [ Note 1: For example,class_type
could be a specialization of a class template that has not been instantiated or explicitly specialized. — end note ] Eachti
designates a type that is valid types for data members. IfoK.width
(for someK
) contains a valuew
, the corresponding typetK
is a valid type for bit field of widthw
. IfoK.alignment
(for someK
) contains a valuea
,alignas(a)
is a validalignment-specifier
for a non-static data member of typetK
.6 Effects: Defines
class_type
with properties as follows:
- (6.1) If
class_type
designates a specialization of a class template, the specialization is explicitly specialized.- (6.2) Non-static data members are declared in the definition of
class_type
according tod1
,d2
, …,dN
, in that order.- (6.3) The type of the respective members are the types denoted by the reflection values
t1
,t2
, …tN
.- (6.4) If
oK.no_unique_address
(for someK
) istrue
, the corresponding member is declared with attribute[[no_unique_address]]
.- (6.5) If
oK.width
(for someK
) contains a value, the corresponding member is declared as a bit field with that value as its width.- (6.6) If
oK.alignment
(for someK
) contains a valuea
, the corresponding member is aligned as if declared withalignas(a)
.- (6.7) If
oK.name
(for someK
) does not contain a value, the corresponding member is declared with an implementation-defined name. Otherwise, the corresponding member is declared with a name corresponding to thestring
oru8string
value that was used to initializeoK.name
.- (6.8) If
class_type
is a union type and any of its members is not trivially default constructible, then it has a default constructor that is user-provided and has no effect. Ifclass_type
is a union type and any of its members is not trivially default destructible, then it has a default destructor that is user-provided and has no effect.7 Returns:
class_type
.
1 Subclause [meta.reflection.unary] contains consteval functions that may be used to query the properties of a type at compile time.
2 For each function taking an argument of type
meta::info
whose name containstype
, a call to the function is a non-constant library call (3.34 [defns.nonconst.libcall]) if that argument is not a reflection of a type or type alias. For each function taking an argument namedtype_args
, a call to the function is a non-constant library call if anymeta::info
in that range is not a reflection of a type or a type alias.
1 For any type or type alias
T
, for each functionstd::meta::type_TRAIT
defined in this clause,std::meta::type_TRAIT(^T)
equals the value of the corresponding unary type traitstd::TRAIT_v<T>
as specified in 21.3.5.2 [meta.unary.cat].consteval bool type_is_void(info type); consteval bool type_is_null_pointer(info type); consteval bool type_is_integral(info type); consteval bool type_is_floating_point(info type); consteval bool type_is_array(info type); consteval bool type_is_pointer(info type); consteval bool type_is_lvalue_reference(info type); consteval bool type_is_rvalue_reference(info type); consteval bool type_is_member_object_pointer(info type); consteval bool type_is_member_function_pointer(info type); consteval bool type_is_enum(info type); consteval bool type_is_union(info type); consteval bool type_is_class(info type); consteval bool type_is_function(info type); consteval bool type_is_reflection(info type);
[ Example 1:— end example ]namespace std::meta { consteval bool type_is_void(info type) { // one example implementation return extract<bool>(substitute(^is_void_v, {type})); // another example implementation type = dealias(type); return type == ^void || type == ^const void || type == ^volatile void || type == ^const volatile void; } }
1 For any type or type alias
T
, for each functionstd::meta::type_TRAIT
defined in this clause,std::meta::type_TRAIT(^T)
equals the value of the corresponding unary type traitstd::TRAIT_v<T>
as specified in 21.3.5.3 [meta.unary.comp].consteval bool type_is_reference(info type); consteval bool type_is_arithmetic(info type); consteval bool type_is_fundamental(info type); consteval bool type_is_object(info type); consteval bool type_is_scalar(info type); consteval bool type_is_compound(info type); consteval bool type_is_member_pointer(info type);
1 For any type or type alias
T
, for each functionstd::meta::type_UNARY-TRAIT
defined in this clause with signaturebool(std::meta::info)
,std::meta::type_UNARY-TRAIT(^T)
equals the value of the corresponding type propertystd::UNARY-TRAIT_v<T>
as specified in 21.3.5.4 [meta.unary.prop].2 For any types or type aliases
T
andU
, for each functionstd::meta::type_BINARY-TRAIT
defined in this clause with signaturebool(std::meta::info, std::meta::info)
,std::meta::type_BINARY-TRAIT(^T, ^U)
equals the value of the corresponding type propertystd::BINARY-TRAIT_v<T, U>
as specified in 21.3.5.4 [meta.unary.prop].3 For any type or type alias
T
, pack of types or type aliasesU...
, and ranger
such thatranges::to<vector>(r) == vector{^U...}
istrue
, for each function templatestd::meta::type_VARIADIC-TRAIT
defined in this clause,std::meta::type_VARIADIC-TRAIT(^T, r)
equals the value of the corresponding type propertystd::VARIADIC-TRAIT_v<T, U...>
as specified in 21.3.5.4 [meta.unary.prop].consteval bool type_is_const(info type); consteval bool type_is_volatile(info type); consteval bool type_is_trivial(info type); consteval bool type_is_trivially_copyable(info type); consteval bool type_is_standard_layout(info type); consteval bool type_is_empty(info type); consteval bool type_is_polymorphic(info type); consteval bool type_is_abstract(info type); consteval bool type_is_final(info type); consteval bool type_is_aggregate(info type); consteval bool type_is_signed(info type); consteval bool type_is_unsigned(info type); consteval bool type_is_bounded_array(info type); consteval bool type_is_unbounded_array(info type); consteval bool type_is_scoped_enum(info type); template <reflection_range R = span<info const>> consteval bool type_is_constructible(info type, R&& type_args); consteval bool type_is_default_constructible(info type); consteval bool type_is_copy_constructible(info type); consteval bool type_is_move_constructible(info type); consteval bool type_is_assignable(info type_dst, info type_src); consteval bool type_is_copy_assignable(info type); consteval bool type_is_move_assignable(info type); consteval bool type_is_swappable_with(info type_dst, info type_src); consteval bool type_is_swappable(info type); consteval bool type_is_destructible(info type); template <reflection_range R = span<info const>> consteval bool type_is_trivially_constructible(info type, R&& type_args); consteval bool type_is_trivially_default_constructible(info type); consteval bool type_is_trivially_copy_constructible(info type); consteval bool type_is_trivially_move_constructible(info type); consteval bool type_is_trivially_assignable(info type_dst, info type_src); consteval bool type_is_trivially_copy_assignable(info type); consteval bool type_is_trivially_move_assignable(info type); consteval bool type_is_trivially_destructible(info type); template <reflection_range R = span<info const>> consteval bool type_is_nothrow_constructible(info type, R&& type_args); consteval bool type_is_nothrow_default_constructible(info type); consteval bool type_is_nothrow_copy_constructible(info type); consteval bool type_is_nothrow_move_constructible(info type); consteval bool type_is_nothrow_assignable(info type_dst, info type_src); consteval bool type_is_nothrow_copy_assignable(info type); consteval bool type_is_nothrow_move_assignable(info type); consteval bool type_is_nothrow_swappable_with(info type_dst, info type_src); consteval bool type_is_nothrow_swappable(info type); consteval bool type_is_nothrow_destructible(info type); consteval bool type_is_implicit_lifetime(info type); consteval bool type_has_virtual_destructor(info type); consteval bool type_has_unique_object_representations(info type); consteval bool type_reference_constructs_from_temporary(info type_dst, info type_src); consteval bool type_reference_converts_from_temporary(info type_dst, info type_src);
1 For any type or type alias
T
, for each functionstd::meta::type_PROP
defined in this clause with signaturesize_t(std::meta::info)
,std::meta::type_PROP(^T)
equals the value of the corresponding type propertystd::PROP_v<T>
as specified in 21.3.6 [meta.unary.prop.query].2 For any type or type alias
T
and unsigned integer valueI
,std::meta::type_extent(^T, I)
equalsstd::extent_v<T, I>
([meta.unary.prop.query]).consteval size_t type_alignment_of(info type); consteval size_t type_rank(info type); consteval size_t type_extent(info type, unsigned i = 0);
1 The consteval functions specified in this clause may be used to query relationships between types at compile time.
2 For any types or type aliases
T
andU
, for each functionstd::meta::type_REL
defined in this clause with signaturebool(std::meta::info, std::meta::info)
,std::meta::type_REL(^T, ^U)
equals the value of the corresponding type relationstd::REL_v<T, U>
as specified in 21.3.7 [meta.rel].3 For any type or type alias
T
, pack of types or type aliasesU...
, and ranger
such thatranges::to<vector>(r) == vector{^U...}
istrue
, for each binary function templatestd::meta::type_VARIADIC-REL
,std::meta::type_VARIADIC-REL(^T, r)
equals the value of the corresponding type relationstd::VARIADIC-REL_v<T, U...>
as specified in 21.3.7 [meta.rel].4 For any types or type aliases
T
andR
, pack of types or type aliasesU...
, and ranger
such thatranges::to<vector>(r) == vector{^U...}
istrue
, for each ternary function templatestd::meta::type_VARIADIC-REL-R
defined in this clause,std::meta::type_VARIADIC-REL-R(^R, ^T, r)
equals the value of the corresponding type relationstd::VARIADIC-REL-R_v<R, T, U...>
as specified in 21.3.7 [meta.rel].consteval bool type_is_same(info type1, info type2); consteval bool type_is_base_of(info type_base, info type_derived); consteval bool type_is_convertible(info type_src, info type_dst); consteval bool type_is_nothrow_convertible(info type_src, info type_dst); consteval bool type_is_layout_compatible(info type1, info type2); consteval bool type_is_pointer_interconvertible_base_of(info type_base, info type_derived); template <reflection_range R = span<info const>> consteval bool type_is_invocable(info type, R&& type_args); template <reflection_range R = span<info const>> consteval bool type_is_invocable_r(info type_result, info type, R&& type_args); template <reflection_range R = span<info const>> consteval bool type_is_nothrow_invocable(info type, R&& type_args); template <reflection_range R = span<info const>> consteval bool type_is_nothrow_invocable_r(info type_result, info type, R&& type_args);
5 [ Note 1: If
t
is a reflection of the typeint
andu
is a reflection of an alias to the typeint
, thent == u
isfalse
buttype_is_same(t, u)
istrue
.t == dealias(u)
is alsotrue
. — end note ].
1 Subclause [meta.reflection.trans] contains consteval functions that may be used to transform one type to another following some predefined rule.
1 For any type or type alias
T
, for each functionstd::meta::type_MOD
defined in this clause,std::meta::type_MOD(^T)
returns the reflection of the corresponding typestd::MOD_t<T>
as specified in 21.3.8.2 [meta.trans.cv].consteval info type_remove_const(info type); consteval info type_remove_volatile(info type); consteval info type_remove_cv(info type); consteval info type_add_const(info type); consteval info type_add_volatile(info type); consteval info type_add_cv(info type);
1 For any type or type alias
T
, for each functionstd::meta::type_MOD
defined in this clause,std::meta::type_MOD(^T)
returns the reflection of the corresponding typestd::MOD_t<T>
as specified in 21.3.8.3 [meta.trans.ref].consteval info type_remove_reference(info type); consteval info type_add_lvalue_reference(info type); consteval info type_add_rvalue_reference(info type);
1 For any type or type alias
T
, for each functionstd::meta::type_MOD
defined in this clause,std::meta::type_MOD(^T)
returns the reflection of the corresponding typestd::MOD_t<T>
as specified in 21.3.8.4 [meta.trans.sign].consteval info type_make_signed(info type); consteval info type_make_unsigned(info type);
1 For any type or type alias
T
, for each functionstd::meta::type_MOD
defined in this clause,std::meta::type_MOD(^T)
returns the reflection of the corresponding typestd::MOD_t<T>
as specified in 21.3.8.5 [meta.trans.arr].consteval info type_remove_extent(info type); consteval info type_remove_all_extents(info type);
1 For any type or type alias
T
, for each functionstd::meta::type_MOD
defined in this clause,std::meta::type_MOD(^T)
returns the reflection of the corresponding typestd::MOD_t<T>
as specified in 21.3.8.6 [meta.trans.ptr].consteval info type_remove_pointer(info type); consteval info type_add_pointer(info type);
[ Editor's note: There
are four transformations that are deliberately omitted here.
type_identity
and
enable_if
are not useful,
conditional(cond, t, f)
would
just be a long way of writing
cond ? t : f
, and
basic_common_reference
is a
class template intended to be specialized and not directly invoked.
]
1 For any type or type alias
T
, for each functionstd::meta::type_MOD
defined in this clause with signaturestd::meta::info(std::meta::info)
,std::meta::type_MOD(^T)
returns the reflection of the corresponding typestd::MOD_t<T>
as specified in 21.3.8.7 [meta.trans.other].2 For any pack of types or type aliases
T...
and ranger
such thatranges::to<vector>(r) == vector{^T...}
istrue
, for each unary function templatestd::meta::type_VARIADIC-MOD
defined in this clause,std::meta::type_VARIADIC-MOD(r)
returns the reflection of the corresponding typestd::VARIADIC-MOD_t<T...>
as specified in 21.3.8.7 [meta.trans.other].3 For any type or type alias
T
, pack of types or type aliasesU...
, and ranger
such thatranges::to<vector>(r) == vector{^U...}
istrue
,std::meta::type_invoke_result(^T, r)
returns the reflection of the corresponding typestd::invoke_result_t<T, U...>
(21.3.8.7 [meta.trans.other]).consteval info type_remove_cvref(info type); consteval info type_decay(info type); template <reflection_range R = span<info const>> consteval info type_common_type(R&& type_args); template <reflection_range R = span<info const>> consteval info type_common_reference(R&& type_args); consteval info type_underlying_type(info type); template <reflection_range R = span<info const>> consteval info type_invoke_result(info type, R&& type_args); consteval info type_unwrap_reference(info type); consteval info type_unwrap_ref_decay(info type);
[ Example 1:— end example ]// example implementation consteval info type_unwrap_reference(info type) { = dealias(type); type if (has_template_arguments(type) && template_of(type) == ^reference_wrapper) { return type_add_lvalue_reference(template_arguments_of(type)[0]); } else { return type; } }
This is a feature with both a language and library component. Our
usual practice is to provide something like
__cpp_impl_reflection
and
__cpp_lib_reflection
for this. But
since the two pieces are so closely tied together, maybe it really only
makes sense to provide one?
For now, we’ll add both.
To 15.11 [cpp.predefined]:
__cpp_impl_coroutine 201902L __cpp_impl_destroying_delete 201806L __cpp_impl_three_way_comparison 201907L+ __cpp_impl_reflection 2024XXL
and 17.3.2 [version.syn]:
+ #define __cpp_lib_reflection 2024XXL // also in <meta>