The Syntax of Static Reflection

• Expressivity. The syntax must support a wide array of metaprogramming use cases. Broadly, we need syntax to a) inspect the compile-time properties of expressions, names, declarations, and entities, b) splice entity references and expressions back into source code, and c) expand such splices in contexts where pack expansion is allowed. • Readability. Obviously, we’d like our programs to be readable. We want syntax that is both visually distinctive yet comprehensible. Because metaprogramming (especially splicing) includes several new C++ programming concepts, we think the notation should be different than conventional notations for e.g., function call and template instantiation. • Flexibility. We shouldn’t design notation that prevents future extensions. We should also consider future extensions to metaprogramming (like code injection) so that we don’t end up with wildly different notations for similar kinds of functionality. • Lack of ambiguity. The grammar for these terms should be as unambiguous as practical, both technically (i.e., not requiring parsing heroics) and visually (i.e., not confusing for a normal C++ programmer). • Implementability. Syntax and semantics that cannot be supported by all implementations is not viable. The variety of syntactic and semantic analysis techniques used by different implementations is known to complicate, if not disqualify, seemingly simple or obvious ideas. We can’t force implementers to standardize on technique.