P1306R5 template for pull request.

[XRay3D]

How should I format the commits and submit a pull request?
I cannot reference issue [GNATS 26474] (C++26: P1306R5) using a [GH #123] tag, as no such issue exists—nor can one be created.
I am working on implementing P1306R5 in EDG.
It seems to me that this will be faster to accomplish than writing P3294R2 ("Code Injection with Token Sequences") for GCC—though I have, in fact, already littelbit made a start on that as well.
Or can I just submit a pull request in a free‑form manner?

[daveedvdv-nvidia]

Hello!

Note that Christof (@nv-cmeerw) is quite far along already on the implementation of P1306R5. Please coordinate with him...

It seems to me that this will be faster to accomplish than writing P3294R2 ("Code Injection with Token Sequences") for GCC—though I have, in fact, already littelbit made a start on that as well.

There should already be support for P3294R2, but note that that is not part of the working paper yet. Also, there is a followup paper for that one: [P4380](https://wg21.link/ p4380).

Bug fixes in the current injection support are welcome, but new features (incl. syntactic alternatives) should probably be kept in a fork or branch because this area is very much in flux.

Or can I just submit a pull request in a free‑form manner?

I'd start with discussions here and wait for a green light to open a corresponding issue.

@DarkArc : Thoughts?

[wchilders-nvidia]

I went ahead and opened an issue (#216), but yeah this is being worked on already by @nv-cmeerw.

Really appreciate your interest @XRay3D; I apologize for the growing pains as we get project management things up and running (ideally for an accepted language feature like this, we would have created the issue already).

[XRay3D]

Your compiler is very compact and builds incredibly fast 🚀.
As soon as I found out it was open-source, I built it myself.
This coincided with my two-week vacation 😀.
I couldn't wait to experiment with P3294 (Code Injection with Token Sequences) locally in my own projects.
However, I was disappointed by the absence of P1306, since I’m already actively using reflection and template for (from GCC 16) in my projects. So, I immediately started looking at the code and trying to add it. I’ve already got it partially working. Along the way, the CWG3XXX pair (I don’t remember the numbers) were repaired and passed the tests.
Okay, I’ll contact @nv-cmeerw (if I find his contacts), my mail xray3d@ya.ru.

[nv-cmeerw]

As mentioned, I am actively working on this feature. I am afraid I am not really sure how to meaningfully split it up - it's mainly the template machinery interactions that I still need to work on.

[XRay3D]

As mentioned, I am actively working on this feature. I am afraid I am not really sure how to meaningfully split it up - it's mainly the template machinery interactions that I still need to work on.

I won't pretend otherwise—I couldn't have done it without the help of AI.

https://github.com/XRay3D/EDG-compiler/tree/template_for

These preliminary ideas might be useful if you have already started implementation. I wasn't aware that work on this was already underway. I won't continue; you likely know better how to do this right and will come up with a superior solution.

This branch contains front end support partialy for template for ([stmt.expand]), adopted for C++26 via P1306R5.

What is supported

All three forms of the expansion statement:

• Enumerating. The expansion-initializer is an expansion-init-list ({ ... }), and each element initializes one expansion.
• Iterating. The expansion-initializer is expansion-iterable. The range, begin and end are bound to exposition-only static constexpr variables, and the i-th element is *(begin + i).
• Destructuring. The elements come from the structured binding protocol.

break ends the whole expansion statement, and continue goes to the end of the current expansion. Identifier labels and case labels of an enclosing switch are rejected in the body.

Implementation notes

• IL representation (IL CHANGE). An expansion statement is a block that holds the init-statement, the exposition-only variables, and one block per expansion. The body tokens are cached and scanned once per expansion.
• New a_block flags. is_expansion_statement and is_expansion let the constexpr interpreter resolve the branches generated for break and continue.
• New a_variable flag. is_synthesized_declared_variable marks the exposition-only variables. They are represented by declaration statements so that back ends can emit them.
• Feature flag. expansion_statements is set in C++26 mode and can be controlled with --set_flag and --clear_flag. Other C++ modes accept the feature with a warning.
• Feature-test macro. __cpp_expansion_statements is defined as 202506L.
• New diagnostics for ill-formed expansion statements: a non-compound body, storage class specifiers, type definitions in the for-range-declaration, a non-constant iterating initializer, and others.

Tests

• New tests. cwg/P1306R5a.sft.cpp covers semantics, cwg/P1306R5b.sft.cpp covers diagnostics, and cwg/P1306R5c.sft.cpp combines expansion statements with reflection. The last one iterates over the enumerators of an enumeration and the non-static data members of a class. The exp_meta header pack is now available to the cwg suite for it.
• Now passing. cwg3043, cwg3048 and cwg3061. cwg3043 passes only in the default configuration (see below).
• Updated expectations. cwg3044, cwg3119, cwg3123, cwg3140 and cwg3149 still fail, but they now report the actual cause instead of "explicit instantiation is not allowed in the current scope".

Known issues

These are recorded in the expectation files and should be fixed before or soon after merging.

• break/continue in constant evaluation are wrong in the edg_x86_64_cp configuration. In P1306R5a, break also leaves the enclosing while loop, and continue behaves like break. The default configuration is correct.
• cwg3043 prints garbage in the edg_x86_64_cp configuration. The generated C++ does not extend the lifetime of temporaries in the expansion-initializer, so v refers to a destroyed object.
• cwg3045 now fails (false negative). It used to pass only because template for was not parsed. The body of an expansion statement with no expansions is not checked, because it is not a template definition in the front end's representation.
• Diagnostics in the body repeat once per expansion. For example, P1306R5b reports the same conversion error three times.
• cwg3119 produces cascading errors after the correct "structured binding pack can only be declared inside a template".

Not yet implemented

CWG 3044, 3119, 3123, 3140 and 3149, as listed in src/Changes.

Other

.gitignore now ignores the QtCreator directory.

🤖 Generated with Claude Code

[XRay3D]

template machinery interactions

How template for works with templates in branch

Inside a template, template for is not expanded when the template is defined. It is scanned once as a dependent statement, and the real expansion happens at instantiation. Every template scenario I tested works correctly, but there are two quirks in diagnostics.

How it works

• Expansion is deferred. Inside a template definition, statements.c always sets the defer-expansion flag. It does not matter whether the initializer depends on template parameters, so even {1, 2, 3} is not expanded.
• The body is scanned once as a dependent statement. The declaration and the body are scanned a single time. If the variable is declared with auto, its type is replaced by a dependent type, and the body is checked like any other dependent code. init_dependent_expansion_variable in expr.c does this replacement.
• Expansion happens at instantiation. The tokens of the declaration and the body are cached. At instantiation they are rescanned once per element. By then the form of the statement is known: enumerating, iterating or destructuring.
• Nested case. Inside a real instantiation, expansion happens immediately.

What was verified

The front end was built in build/ in the Debug configuration, and a set of examples was checked with static_assert. Executables were not run because the runtime library is not built.

These cases work correctly:

• expanding a pack of type parameters and a pack of non-type parameters, including an empty pack;
• nested template for over two different packs in a member template of a class template;
• a member of a class template defined outside the class;
• a generic lambda;
• if constexpr on the element type;
• iterating over a static constexpr object of dependent type;
• instantiation with an array;
• destructuring an aggregate;
• a structured binding pack inside a template;
• a lambda and a local class in the body, with one instance per expansion;
• break and continue in constant evaluation of a function template;
• a variable type given by a template parameter.

Quirks

• Errors that depend on the element appear only at instantiation. A failing static_assert(sizeof(x) == 8) in the body with the initializer {1, 2, 3} is not reported until the template is instantiated. This is allowed: such a template is ill-formed, but the standard does not require a diagnostic. Errors that depend on nothing, such as int z = "str";, are reported at definition time.
• Errors repeat once per expansion. An error in the body is printed once per expanded element, with the same position and text each time. Outside templates the behavior is the same. Right now, suppression after the first expansion applies only to errors that depend solely on the tokens.
• An empty expansion checks nothing. With an empty pack the body is not scanned at all, so errors in it are never reported, even after instantiation. This is the same limitation that makes cwg3045 fail.

These checks were not run in the edg_x86_64_cp configuration, where break and continue are broken. Only the default front end was built.

[nv-cmeerw]

Thanks. I haven't looked in detail at it, but one thing that stood out so far is that this doesn't represent the expansion statement in the non-expanded form in the IL (I'd expect to have a new expansion statement kind in the IL that represents the source representation of the expansion statement - this is important for source analysis users, and I'd also expect that cp_gen_be would reconstruct that expansion statement in its output).

I'll keep those notes in mind in the hope I won't miss anything.