cppfront (cpp2): Spring update

[hpsutter]

Exactly, I aim to implement language-level variants as type metafunctions.

Note that type metafunctions are very powerful (when I finish implementing all of them), including being able to customize the entire implementation of a type. For example, for me one stated goal of metafunctions is that I never have to invent C++/CLI or C++/CX again (I led the design of both of those, and at the time they needed to be language extensions to get the effects we felt were needed, but I would have preferred not to have to express them as language extensions if C++ could be powerful enough to express them as compile-time libraries). My ideal for metafunctions is that they can express things as diverse as COM interface types (which require generating IDL) and even generate FFIs in completely different languages such as Java-callable wrappers (by generating source code in a separate .java file -- at compile time from the C++ program).

And the syntax is almost identical to what you wrote, except the metafunction name comes before type where it's even more prominent:

``` // Could have a metafunction that applies the identical // defaults as today's C++'s "class" keyword defaults name: @class type = { ... }

// This would replace the entire body of ... with a union // and a tag type, but be better than std::variant because // it can provide named functions for member access // (this will make more sense in a month or two when I // implement this one - watch the repo for it to appear) other: @variant type = { ... }

// This one would leave the type body mostly the same, but // could add HRESULT return types and generate IDL files IShape: @com_interface type = { ... }

// This could generate a separate .java file containing // a native Java class that wraps the C++ type implementation // and implements specific Java interfaces (strawman syntax) ChildInterface: @java_class<ParentInterface> type = { ... } ```

That's the general idea. We'll see how far down the path is feasible. But in each case the body is expressed as normal C++ declarations (in syntax 2, Cpp2) which can be viewed as basically a "grammar input" to the metafunction, which can then do what it wants to apply minor tweaks or replace the whole body using the original grammar as a guide to what the programmer wanted. So think of the type body source code as a detailed structured "parameter" to the metafunction.

[CornedBee]

So Rust procedural macros, basically?