Cpp1 reflection: Cpp2 syntax

[JohelEGP]

Let's discuss the Cpp2 syntax for https://wg21.link/P2996.

I take it for granted that Cpp1 syntax for reflecting ^int will be Cpp2 int^.

So what about the syntax for splicing (https://wg21.link/p2996r0#splicers)?
Below is a tony table based on R0 ("Reflection for C++26") for you to fill in the ?s.

Note that Cpp2 already uses @ for type metafunctions
(with interpretation in the message of commit d8c1a50,
see the first list item under "Re syntax:").

With #533 and #727, I hope we don't need disambiguating typename or template for Cpp2.
The grammar should make it clear what kind of entity is expected where.
I think it's reasonable to also aim for a single splicing syntax without disambiguating keywords.

Markdown table to be filled.

| Cpp1 code                                                        | Cpp2 code                                           |
|:-----------------------------------------------------------------|:----------------------------------------------------|
| <https://wg21.link/p2996r0#back-and-forth>                       |                                                     |
| `constexpr auto r = ^int;`                                       | `r :== int^;`                                       |
| `typename[:r:] x = 42;`                                          | `x: ? = 42;`                                        |
| `typename[:^char:] c = '*';`                                     | `c: ? = '*';`                                       |
| `using MyType = [:sizeof(int)<sizeof(long)? ^long : ^int:];`     | `MyType: type == ?;`                                |
| <https://wg21.link/p2996r0#selecting-members>                    |                                                     |
| `s.[:member_number(1):] = 42;`                                   | `s.? = 42;`                                         |
| <https://wg21.link/p2996r0#list-of-types-to-list-of-sizes>       |                                                     |
| `constexpr std::array types = {^int, ^float, ^double};`          | `types: std::array == (int^, float^, double^);`     |
| <https://wg21.link/p2996r0#implementing-make_integer_sequence>   |                                                     |
| `return substitute(^std::integer_sequence, args);`               | `return std::integer_sequence^.substitute(args);`   |
| <https://wg21.link/p2996r0#enum-to-string>                       |                                                     |
| `if (value == [:e:]) {`                                          | `if value == ? {`                                   |
| `return [:e:];`                                                  | `return ?;`                                         |
| <https://wg21.link/p2996r0#parsing-command-line-options>         |                                                     |
| `if (iss >> opts.[:dm:]; !iss) {`                                | `if (iss >> opts.?; !iss) {`                        |
| <https://wg21.link/p2996r0#a-simple-tuple-type>                  |                                                     |
| `using type = [: template_arguments_of(^Tuple<Ts...>)[I] :];`    | `type: type == ?;`                                  |
| `t.data.[:nonstatic_data_members_of(^decltype(t.data))[I]:]`     | `t.data.?`                                          |
| <https://wg21.link/p2996r0#parsing-command-line-options-ii>      |                                                     |
| `auto const& cur = spec.[:sm:];`                                 | `(cur := spec.?) {`                                 |
| `auto const& cur = spec.[:sm:];`                                 | `cur := spec.?&;`                                   |
| `auto const& cur = spec.[:sm:];`                                 | `cur: gsl::not_null = spec.?&;`                     |
| `if constexpr (template_of(om) == ^std::optional) {`             | `if constexpr om.template_of() == std::optional^ {` |
| `opts.[:om:] = *cur.initializer;`                                | `opts.? = cur.initializer*;`                        |
| <https://wg21.link/p2996r0#a-universal-formatter>                |                                                     |
| `static_cast<[:base:] const&>(t)`                                | `static_cast<* const ?>(t&)*`                       |
| <https://wg21.link/p2996r0#implementing-member-wise-hash_append> |                                                     |
| `hash_append(algo, t.[:mem:]);`                                  | `algo.hash_append(t.?);`                            |
| <https://wg21.link/p2996r0#converting-a-struct-to-a-tuple>       |                                                     |
| `return std::make_tuple(t.[: members[Is] :]...);`                | `return std::make_tuple(t.?...);`                   |
| `return To(from.[:members:]...);`                                | `return To(from.?...);`                             |
| `using To = [: struct_to_tuple_type(^From) :];`                  | `To: type == ?;`                                    |
| <https://wg21.link/p2996r0#stdmetainfo>                          |                                                     |
| `int x = 0;`                                                     | `x: int = 0;`                                       |
| `[:^x:] = 42;`                                                   | `? = 42;`                                           |
| `x = [:^(2*N):];`                                                | `x = ?;`                                            |

[JohelEGP]

This is the idea that motivated me to start this discussion.
I hadn't thought too much about @ or the many cases in the table.

The idea is to complement ^ with v (yes, an identifier).
This means int being equivalent to int^v.
Or Cpp1 [:r:] being equivalent to Cpp2 r v (space required).

This formulation isn't problematic like multi-token types are (e.g, long long).

Grammar diff

 //G postfix-operator:
-//G     one of  '++' '--' '*' '&' '~' '$' '...'
+//G     one of  '++' '--' '*' '&' '~' '$' '...' 'v'
 //G
 //G postfix-expression:
 //G     primary-expression
-//G     postfix-expression postfix-operator     [Note: without whitespace before the operator]
+//G     postfix-expression postfix-operator     [Note: without whitespace before the operator, except for `v`]
 //G
 //G unqualified-id:
 //G     identifier
 //G     keyword
 //G     template-id
 //GTODO     operator-function-id
 //G     ...
+//G     '(' expression 'v' ')'

New semantics

Cpp2 x.(r v) is Cpp1 x.[:r:].
These parentheses are necessary because Cpp2 x.r v is Cpp1 [:x.r:].
I do not like further overloading parentheses.

Why not prefix.

Under the usual rules (except for forward in Cpp2),
postfix operators apply to "everything" on the left, and
prefix operators apply to "everything" on the right.

If v was prefix x.v y.z would be Cpp1 x.[:y.z:].
We would need parentheses, x.v (y).z.
That smells too much like a function call.

If v behaved like forward,
x.v y.z would be Cpp1 x.[:y:].z.
But we would still need parentheses for non primary expressions like x.v (y.w).z.

Cpp1 code	Cpp2 code
https://wg21.link/p2996r0#back-and-forth
constexpr auto r = ^int;	r :== int^;
typename[:r:] x = 42;	x: r v = 42;
typename[:^char:] c = '*';	c: char^v = '*';
using MyType = [:sizeof(int)<sizeof(long)? ^long : ^int:];	MyType: type == :std::array = (long^, int^)[index];
https://wg21.link/p2996r0#selecting-members
s.[:member_number(1):] = 42;	s.(member_number(1) v) = 42;
https://wg21.link/p2996r0#list-of-types-to-list-of-sizes
constexpr std::array types = {^int, ^float, ^double};	types: std::array == (int^, float^, double^);
https://wg21.link/p2996r0#implementing-make_integer_sequence
return substitute(^std::integer_sequence, args);	return std::integer_sequence^.substitute(args);
https://wg21.link/p2996r0#enum-to-string
if (value == [:e:]) {	if value == e v {
return [:e:];	return e v;
https://wg21.link/p2996r0#parsing-command-line-options
if (iss >> opts.[:dm:]; !iss) {	if (iss >> opts.(dm v); !iss) {
https://wg21.link/p2996r0#a-simple-tuple-type
using type = [: template_arguments_of(^Tuple<Ts...>)[I] :];	type: type == Tuple<Ts...>^.template_arguments_of()[I] v;
t.data.[:nonstatic_data_members_of(^decltype(t.data))[I]:]	t.data.(decltype(t.data)^.nonstatic_data_members_of()[I] v)
https://wg21.link/p2996r0#parsing-command-line-options-ii
auto const& cur = spec.[:sm:];	(cur := spec.(sm v)) {
auto const& cur = spec.[:sm:];	cur := spec.(sm v)&;
auto const& cur = spec.[:sm:];	cur: gsl::not_null = spec.(sm v)&;
if constexpr (template_of(om) == ^std::optional) {	if constexpr om.template_of() == std::optional^ {
opts.[:om:] = *cur.initializer;	opts.(om v) = cur.initializer*;
https://wg21.link/p2996r0#a-universal-formatter
static_cast<[:base:] const&>(t)	static_cast<* const base v>(t&)*
https://wg21.link/p2996r0#implementing-member-wise-hash_append
hash_append(algo, t.[:mem:]);	algo.hash_append(t.(mem v));
https://wg21.link/p2996r0#converting-a-struct-to-a-tuple
return std::make_tuple(t.[: members[Is] :]...);	return std::make_tuple(t.(members[Is] v)...);
return To(from.[:members:]...);	return To(from.(members v)...);
using To = [: struct_to_tuple_type(^From) :];	To: type == From^.struct_to_tuple_type() v;
https://wg21.link/p2996r0#stdmetainfo
int x = 0;	x: int = 0;
[:^x:] = 42;	x^v = 42;
x = [:^(2*N):];	x = (2*N)^v;

[JohelEGP]

The only difference between postfix v and postfix @
would be the space allowed between an identifier and v.

[AbhinavK00]

On a discussion on reddit about reflection, someone pointed out that

Splices require an opening and closing delimiter so that you can put expressions inside which evaluate to a meta::info.

I don't know if they're correct or not but i think it makes sense.

Secondly, the v syntax reads badly IMO.
The ^ syntax will clash with bitwise xor operator and therefore whitespace would have to be used to disambiguate (similar to *).
I was under the impression that @ was supposed to tie more broadly into whole of reflection. It is already being used for metafuntions in prefix form, why not use it as reflecting operator in postfix form? Are there supposed to be more uses for @? (Maybe it CAN tie into constevel function since all metafunctions are basically constevel functions operating on type meta::info).
If not, then using a whole symbol for a single use case is wasting it IMO.

[JohelEGP]

Yes, I agree that v can be ugly.
Here's what I get if I replace the v's in the table I filled with @.

My proposal with v, but using @.

Cpp1 code	Cpp2 code
https://wg21.link/p2996r0#back-and-forth
constexpr auto r = ^int;	r :== int^;
typename[:r:] x = 42;	x: r@ = 42;
typename[:^char:] c = '*';	c: char^@ = '*';
using MyType = [:sizeof(int)<sizeof(long)? ^long : ^int:];	MyType: type == :std::array = (long^, int^)[index];
https://wg21.link/p2996r0#selecting-members
s.[:member_number(1):] = 42;	s.(member_number(1)@) = 42;
https://wg21.link/p2996r0#list-of-types-to-list-of-sizes
constexpr std::array types = {^int, ^float, ^double};	types: std::array == (int^, float^, double^);
https://wg21.link/p2996r0#implementing-make_integer_sequence
return substitute(^std::integer_sequence, args);	return std::integer_sequence^.substitute(args);
https://wg21.link/p2996r0#enum-to-string
if (value == [:e:]) {	if value == e@ {
return [:e:];	return e@;
https://wg21.link/p2996r0#parsing-command-line-options
if (iss >> opts.[:dm:]; !iss) {	if (iss >> opts.(dm@); !iss) {
https://wg21.link/p2996r0#a-simple-tuple-type
using type = [: template_arguments_of(^Tuple<Ts...>)[I] :];	type: type == Tuple<Ts...>^.template_arguments_of()[I]@;
t.data.[:nonstatic_data_members_of(^decltype(t.data))[I]:]	t.data.(decltype(t.data)^.nonstatic_data_members_of()[I]@)
https://wg21.link/p2996r0#parsing-command-line-options-ii
auto const& cur = spec.[:sm:];	(cur := spec.(sm@)) {
auto const& cur = spec.[:sm:];	cur := spec.(sm@)&;
auto const& cur = spec.[:sm:];	cur: gsl::not_null = spec.(sm@)&;
if constexpr (template_of(om) == ^std::optional) {	if constexpr om.template_of() == std::optional^ {
opts.[:om:] = *cur.initializer;	opts.(om@) = cur.initializer*;
https://wg21.link/p2996r0#a-universal-formatter
static_cast<[:base:] const&>(t)	static_cast<* const base@>(t&)*
https://wg21.link/p2996r0#implementing-member-wise-hash_append
hash_append(algo, t.[:mem:]);	algo.hash_append(t.(mem@));
https://wg21.link/p2996r0#converting-a-struct-to-a-tuple
return std::make_tuple(t.[: members[Is] :]...);	return std::make_tuple(t.(members[Is]@)...);
return To(from.[:members:]...);	return To(from.(members@)...);
using To = [: struct_to_tuple_type(^From) :];	To: type == From^.struct_to_tuple_type()@;
https://wg21.link/p2996r0#stdmetainfo
int x = 0;	x: int = 0;
[:^x:] = 42;	x^@ = 42;
x = [:^(2*N):];	x = (2*N)^@;

The ^ syntax will clash with bitwise xor operator and therefore whitespace would have to be used to disambiguate (similar to *).

We already have postfix operators overloaded as binary operators: '*' '&' '~'.
The corresponding design note documents that (https://github.com/hsutter/cppfront/wiki/Design-note%3A-Postfix-unary-operators-vs-binary-operators):

• a^ would be a reflection.
• a^b and a^(b) is an error.
• a ^ b is the binary ^.

On a discussion on reddit about reflection, someone pointed out that

Splices require an opening and closing delimiter so that you can put expressions inside which evaluate to a meta::info.

Right, I remember that bit of trivia.
In my proposal here, we use parentheses instead.
And I do not require them,
so a == b v works just fine,
whereas a.(b v) requires parentheses.

[JohelEGP]

An alternative to parentheses is balanced @s.
I keep postfix @ for when that's sufficient.
But that makes it two ways to spell the same thing, e.g., x: @r@; vs x: r@;.
Or maybe we could say the latter is the default.

The table, using @ (postfix and balanced).

Cpp1 code	Cpp2 code
https://wg21.link/p2996r0#back-and-forth
constexpr auto r = ^int;	r :== int^;
typename[:r:] x = 42;	x: r@ = 42;
typename[:^char:] c = '*';	c: char^@ = '*';
using MyType = [:sizeof(int)<sizeof(long)? ^long : ^int:];	MyType: type == :std::array = (long^, int^)[index];
https://wg21.link/p2996r0#selecting-members
s.[:member_number(1):] = 42;	s.@member_number(1)@ = 42;
https://wg21.link/p2996r0#list-of-types-to-list-of-sizes
constexpr std::array types = {^int, ^float, ^double};	types: std::array == (int^, float^, double^);
https://wg21.link/p2996r0#implementing-make_integer_sequence
return substitute(^std::integer_sequence, args);	return std::integer_sequence^.substitute(args);
https://wg21.link/p2996r0#enum-to-string
if (value == [:e:]) {	if value == e@ {
return [:e:];	return e@;
https://wg21.link/p2996r0#parsing-command-line-options
if (iss >> opts.[:dm:]; !iss) {	if (iss >> opts.@dm@; !iss) {
https://wg21.link/p2996r0#a-simple-tuple-type
using type = [: template_arguments_of(^Tuple<Ts...>)[I] :];	type: type == Tuple<Ts...>^.template_arguments_of()[I]@;
t.data.[:nonstatic_data_members_of(^decltype(t.data))[I]:]	t.data.@decltype(t.data)^.nonstatic_data_members_of()[I]@
https://wg21.link/p2996r0#parsing-command-line-options-ii
auto const& cur = spec.[:sm:];	(cur := spec.@sm@) {
auto const& cur = spec.[:sm:];	cur := spec.@sm@&;
auto const& cur = spec.[:sm:];	cur: gsl::not_null = spec.@sm@&;
if constexpr (template_of(om) == ^std::optional) {	if constexpr om.template_of() == std::optional^ {
opts.[:om:] = *cur.initializer;	opts.@om@ = cur.initializer*;
https://wg21.link/p2996r0#a-universal-formatter
static_cast<[:base:] const&>(t)	static_cast<* const base@>(t&)*
https://wg21.link/p2996r0#implementing-member-wise-hash_append
hash_append(algo, t.[:mem:]);	algo.hash_append(t.@mem@);
https://wg21.link/p2996r0#converting-a-struct-to-a-tuple
return std::make_tuple(t.[: members[Is] :]...);	return std::make_tuple(t.@members[Is]@...);
return To(from.[:members:]...);	return To(from.@members@...);
using To = [: struct_to_tuple_type(^From) :];	To: type == From^.struct_to_tuple_type()@;
https://wg21.link/p2996r0#stdmetainfo
int x = 0;	x: int = 0;
[:^x:] = 42;	x^@ = 42;
x = [:^(2*N):];	x = (2*N)^@;

[JohelEGP]

Another alternative to using parentheses is just \E/ for splicing.
This is similar to the last alternative of P2320R0 The Syntax of Static Reflection.

The table, using \E/ for splicing.

Cpp1 code	Cpp2 code
https://wg21.link/p2996r0#back-and-forth
constexpr auto r = ^int;	r :== int^;
typename[:r:] x = 42;	x: \r/ = 42;
typename[:^char:] c = '*';	c: \char^/ = '*';
using MyType = [:sizeof(int)<sizeof(long)? ^long : ^int:];	MyType: type == :std::array = (long^, int^)[index];
https://wg21.link/p2996r0#selecting-members
s.[:member_number(1):] = 42;	s.\member_number(1)/ = 42;
https://wg21.link/p2996r0#list-of-types-to-list-of-sizes
constexpr std::array types = {^int, ^float, ^double};	types: std::array == (int^, float^, double^);
https://wg21.link/p2996r0#implementing-make_integer_sequence
return substitute(^std::integer_sequence, args);	return std::integer_sequence^.substitute(args);
https://wg21.link/p2996r0#enum-to-string
if (value == [:e:]) {	if value == \e/ {
return [:e:];	return \e/;
https://wg21.link/p2996r0#parsing-command-line-options
if (iss >> opts.[:dm:]; !iss) {	if (iss >> opts.\dm/; !iss) {
https://wg21.link/p2996r0#a-simple-tuple-type
using type = [: template_arguments_of(^Tuple<Ts...>)[I] :];	type: type == \Tuple<Ts...>^.template_arguments_of()[I]/;
t.data.[:nonstatic_data_members_of(^decltype(t.data))[I]:]	t.data.\decltype(t.data)^.nonstatic_data_members_of()[I]/
https://wg21.link/p2996r0#parsing-command-line-options-ii
auto const& cur = spec.[:sm:];	(cur := spec.\sm/) {
auto const& cur = spec.[:sm:];	cur := spec.\sm/&;
auto const& cur = spec.[:sm:];	cur: gsl::not_null = spec.\sm/&;
if constexpr (template_of(om) == ^std::optional) {	if constexpr om.template_of() == std::optional^ {
opts.[:om:] = *cur.initializer;	opts.\om/ = cur.initializer*;
https://wg21.link/p2996r0#a-universal-formatter
static_cast<[:base:] const&>(t)	static_cast<* const \base/>(t&)*
https://wg21.link/p2996r0#implementing-member-wise-hash_append
hash_append(algo, t.[:mem:]);	algo.hash_append(t.\mem/);
https://wg21.link/p2996r0#converting-a-struct-to-a-tuple
return std::make_tuple(t.[: members[Is] :]...);	return std::make_tuple(t.\members[Is]/...);
return To(from.[:members:]...);	return To(from.\members/...);
using To = [: struct_to_tuple_type(^From) :];	To: type == \From^.struct_to_tuple_type()/;
https://wg21.link/p2996r0#stdmetainfo
int x = 0;	x: int = 0;
[:^x:] = 42;	\x^/ = 42;
x = [:^(2*N):];	x = \(2*N)^/;

[realgdman]

I wonder is there chance that restriction about spaces around ^ can be lifted in the future.

[JohelEGP]

From #774 (reply in thread):

An alternative to parentheses is balanced @s.
I keep postfix @ for when that's sufficient.
But that makes it two ways to spell the same thing, e.g., x: @r@; vs x: r@;.

I think allowing both postfix and balanced @s can be ambiguous to the reader of non-highlighted code.
[email protected]@ is [:[:x.y:].z:]; @.z@ itself isn't valid, so the first @ must be postfix.

[JohelEGP]

I think #774 (reply in thread) is my favorite.
It uses @, consistent with its use for consuming metafunctions.
@ is both balanced and postfix, with the latter being the default when balanced would be equivalent.
This makes for less ceremony, but isn't as unambiguous as actual balanced characters
(see the next-to-last item in the introduction to P2320R0 The Syntax of Static Reflection, "lack of ambiguity").

[gregmarr]

@JohelEGP Can you explain what x.(y@) as opposed to x.y@ means?

[JohelEGP]

Consider this:

t: @struct type = {
  e :== int^;
}
f: () == {
  a: t == ();
  _ = a.e@(0); // Cpp1 `static_cast<void>([:a.e:](0))` -> `static_cast<void>((int)(0))`.
  _ = a.(e@)(0); // error: no `e` in scope that can be spliced.
  u :== t^.members()[0];
  _ = a.u@; // error: `t` has no member `u`.
  _ = a.(u@); // Cpp1 `static_cast<void>(a.[:u:])` -> `static_cast<void>(a.e)`.
}

[AbhinavK00]

So you two are in favor of #774 (reply in thread).

Not me, I suggested @ for reflecting, not splicing. What you suggest is using @ for splicing.

[gregmarr]

Yes, I was referring just to reflection, not splicing. I agree that splicing should have paired operators, and ideally they should be two separate operators that are paired so that nesting is unambiguous. That could be either using brackets, or two non-bracket characters that are used in different orders, such as |:splice here:|, or the bracket-like forward and backward slashes.

[msadeqhe]

How about |...|?

opts.|om| = cur.initializer*;

algo.hash_append(t.|mem|);

x: = |(a | b)^|;

[msadeqhe]

It seems operator ^ cannot be combined with other postfix operators:

xabx: == 10;
a: = xabx^++; // ERROR: std::meta::info doesn't have operator++

So operator ^ is almost always the last operator we can use over an expression. Why do not keep it prefix as-is in Cpp1 to easily lookup them?

xabx: == 10;
a: = ^xabx;

[msadeqhe]

Thanks @gregmarr.

@AbhinavK00 Yes, it may be confusing, but it's not unary infix operator, it's binary infix operator:

x.y.^z == (x.y).^(z)
a.b.^c.d == ((a.b).^(c)).d

[AbhinavK00]

First of all, it's not binary. It takes a single argument. Just think about it, in your first example x.y.z is the argument, not x.y and z. z by itself doesn't even make sense, it's not in the scope, you have to enter the scope of x.y just to get to it. So it's a single argument, not two.

Secondly, think about the most simple example, int^ or ^int.
Here, it's a simple unary postfix/prefix operator. What you're basically saying is that same operator behaves two different ways under two different conditions where one of them is never-before-seen. I don't think an infix reflecting operator is any good idea.

[msadeqhe]

Operator .^ is a binary operator which is a syntactic sugar to both binary operator dot and unary operator ^:

a.b.^c == ^(a.b.c)

That's it. It's binary as how operator dot is binary too. Operator .^ is a compound operator that will access the member (or UFCS) and apply unary operator ^ to the result.

[AbhinavK00]

Isn't that too much to achieve something that can be done by a simple unary postfix operator.

[msadeqhe]

Yes, maybe it sounds too much.

On one hand we can have postfix operator ^.

Contrary on the other hand we can have both prefix operator ^ and infix operator .^ to type less parentheses.

[msadeqhe]

Currently $ captures a value. How about $<> to produce grammatical elements from reflections (aka splices):

xabx: = int^;
var1: $<xabx> = 10;

member: = /*reflection*/;
obj.$<member> = 10;

Why $<>?

Because its behavior is similar to $ in string interpolation and code generation. Also <> represents that is a compile-time operation, and it can get anything like templates.

On the other hands, necessarily its syntax is different from both capturing and template argument/parameter list.

[JohelEGP]

From https://github.com/hsutter/cppfront/wiki/Design-note%3A-Capture:

"capture" means "take an expression in this context and store a copy of its current value for use later."

Splicing is different from capture.
So I think there's worth in using a different symbol.

[msadeqhe]

OK. Good point.

[AbhinavK00]

Question: Why not just take the C++ reflection syntax? While cpp2 has been a syntax overhaul, operators have not been changed, merely made postfix. The symbol for a specific operator has been same. Then why change reflection syntax?
And if we ARE changing it, what makes it more important than other changes that could've been useful like the dereference operator?

Note: One notable change could be -> but that has not been changed, it has been outright removed because of presence of a better alternative.

[JohelEGP]

Keeping it the same is a valid alternative.
Just like Cpp2 using-declaration, because Cpp1 using declaration and statement are already left-to-right.
I'm personally hoping for a terser splice syntax.

[JohelEGP]

r/cpp post: Anyone find the proposed reflection syntax distracting?.

[AbhinavK00]

There are more comments which talk about using something other than ^ for reflecting rather than talking about splicing syntax which I find surprising. A lot of people also say they are fine with status quo.

[hsutter]

For reflection, so far I've implemented only reflection on a whole type's source grammar in order to apply a metafunction. There's not as yet a reflection operator to explicitly reflect on a different entity.

For generation, the Cpp2 approach is to always inject (capture) strings that are valid source code grammar, and the context you're asking to parse it as is explicit in the function doing the generation. So far I've implemented one kind of the latter, which is to add to a type scope: type_declaration::add_member(inout this, source: std::string_view) which requires that source be valid a valid grammar production to appear at a type scope. I'll be adding:

• a way to add to an enclosing namespace/type scope as well, to enable useful things like nonmember function generation; and
• a way to do compile-time file output, to enable things like spitting JSON or C# or other output.

[MaxSagebaum]

a way to add to an enclosing namespace/type scope as well, to enable useful things like nonmember function generation; and

Id did this already in this branch: https://github.com/MaxSagebaum/cppfront/tree/feature/declarationsInMetafunctions and created a WIP merge request: #809 I wanted to clean it up this week, and remove my examples.

a way to do compile-time file output, to enable things like spitting JSON or C# or other output.

I do not 100% understand what you mean by this, but there is also a version of the above branch, that builds on top of the work Johel did, that metafunctions can be loaded from libraries. It compiles metafunctions JIT to make them available directly after their definition. Branch: https://github.com/MaxSagebaum/cppfront/tree/feature/program-defined_metafunctions_JIT and I explained it here: #797 (reply in thread)