Thank you for posting the insightful thread about CppMeta as a potential
implementation of C++ reflection. I'd like to ask about bringing code
reflection to C.

I program in both C++ and C. I am imagining, for code reflection in C, a
new preprocessor operator ### (maybe called code-string) to go with #
(stringize) and ## (concatenate). However, unlike # and ##, using ###
isn't limited to within a #define macro...

// C preprocessor ### operator potential example:

enum Color { red, green, blue };

struct Point
{ int x;//some comment
     int y;
     int z;
};

void foo(int x);

const char* s = ###(Color);
puts(s);
/* output:
    enum Color { red, green, blue };
*/
s = ###(Color.2);
puts(s);
/* output:
    enum blue = 2;
*/
s = ###(Point);
puts(s);
/* output:
    struct Point
    { int x;//some comment
        int y;
        int z;
     };
*/
s = ###(Point.x);
puts(s);
/* output:
    int x;
*/
s = ###(Point.1);
puts(s);
/* output (member #1):
    int y;
*/
s = ###(Point.);
puts(s);
/* output (how many members in struct):
    3
*/
s = ###(foo);
puts(s);
/* output:
    void foo(int x);
*/
s = ###(Hello); //compile-time error, Hello doesn't exist

Code-string hasn't been proposed yet. Still at idea stage. CppMeta is
much more sophisticated, seems too sophisticated for C. What are the
most significant features of CppMeta missing in ### concept?

Thoughts?

Robin Rowe
Beverly Hills, California
*Chairman ISO WG21 SG14 C++ Banking and Financial Systems Subcommittee

On 2/20/2024 11:33 AM, Dan Katz (BLOOMBERG/ 919 3RD A) via SG7 wrote:
> Hey everyone,
>
> First of all, thanks to Jean-Baptiste and to Code Reckons for sharing
> the CppMeta compiler! This looks like awesome work, and I'm excited to
> read your subsequent articles regarding the project.
>
> As one of the co-authors of P2996, I think that CppMeta demonstrates
> many of the powerful features we hope to bring to C++ once the
> foundation for Static Reflection has been laid: Injective
> metaprogramming, and reflection over more general expressions, will let
> C++ address problems like lambda serialization, automatic
> differentiation, proxy class generation, and more. Andrew Sutton's P2237
> ("Metaprogramming") paper detailed one vision for how such features
> could be built on top of P2996-style reflection.
>
> One thing that I feel is coming into sharper focus is just how ambitious
> of a change P2996 already represents. Although it's easy to at first see
> our paper as just a pair of new operators and a handful of functions,
> the number of cross-cutting concerns is quite large: Splices of
> expressions can appear in member access expressions; splices of
> namespaces and types can appear as the leading component of nested name
> specifiers; special care is needed when a splice appears as the operand
> of the reflection operator; special rules are needed when using a splice
> as a template argument; and since std::meta::info is a scalar type, any
> of these things can be dependent on a template parameter (including
> namespaces!).
>
> I think that as folks get a good look at implementations of P2996, and
> at the proposed wording that has started to take shape in the R2
> revision (still missing quite a bit of language), they'll see just how
> many changes need to be stitched together to give the impression that
> reflection "just works." P2996 feels to me like the right level of
> ambition for C++26, but it will still take a lot of hard work and a
> little bit of luck for it to land in time.
>
> After that? I'd love to see some of the ideas from CppMeta revisited. As
> I discussed in P3010, I share the project's enthusiasm for "typeful"
> value-based reflection. I recall that SG7 expressed support in Kona for
> eventually adopting a family of such types with std::meta::info as the
> "common denominator". I hope that more folks continue to explore what
> such families of reflection types might look like: It might take some
> time to find the right "granularity" of types (e.g., a 'type_t' seems
> like a given, but the need for a 'pointer_type_t' is less obvious to
> me), and to ensure that the proposed types aren't tied too closely to
> any given implementation's internal data structures. In the meantime,
> Example 17 from P2996R2 suggests one (admittedly less ergonomic) means
> of experimenting with typeful reflection types on top of P2996.
>
> I'm excited to hear more about CppMeta, and I hope its design helps to
> inform what source code injection and typeful reflection might look like
> going forward!
>
> Best,
> ---Dan Katz
>
>
> From: sg7_at_[hidden] At: 02/17/24 16:04:02 UTC-5:00
> To: sg7_at_[hidden] <mailto:sg7_at_[hidden]>
> Cc: jeanbaptiste.vallon_at_[hidden] <mailto:jeanbaptiste.vallon_at_[hidden]>
> Subject: Re: [SG7] CodeReckons CppMeta compiler
>
> Hello everyone,
>
> The differences can be quickly summarized as follows :
>
> - the reflection API is typed
> - the reflection domain includes statements and expressions (so
> we're able to traverse a function's body, for example)
> - anything that can be reflected, can be constructed/injected. so we
> can create expressions, statements, or declarations. Our use cases
> cover operators generation/interface generation (member
> functions synthesis), symbolic differentiation (expressions
> traversal and synthesis), string matching (statements synthesis),
> and static analysis (statements/expressions traversal, inspection of
> functions parameters), among other things.
> - we can emit diagnostics at compile-time, and transform value of
> builtin types to text (we've also constexpr-ised std::format to help
> emit diagnostics)
>
> This is of course a very brief summary of the differences, and they
> will hopefully be better demonstrated by the articles.
>
> -Jean-Baptiste
>
>
> Le ven. 16 févr. 2024 à 20:57, David Sankel via SG7
> <sg7_at_[hidden] <mailto:sg7_at_[hidden]>> a écrit :
>
> Thanks for sending this out Hana. It would be great if someone
> could succinctly summarize how this differs from what was
> already forwarded to EWG.
>
> On Tue, Feb 13, 2024 at 11:44 AM Hana Dusíková via SG7
> <sg7_at_[hidden] <mailto:sg7_at_[hidden]>> wrote:
>
> Hello SG7!
>
> Jean-Baptiste Vallon Hoarau and Joel Falcou recently
> contacted me as they work on on a prototype of reflection
> (different than P2996 as they started a while ago) and it's
> an interesting design. They just announced a blogpost about it.
>
> Hana
>
> <https://www.codereckons.com/articles/65cbc0511318c3d21078737b>
> Code Reckons
> <https://www.codereckons.com/articles/65cbc0511318c3d21078737b>
> codereckons.com
> <https://www.codereckons.com/articles/65cbc0511318c3d21078737b>
> favicon.ico
> <https://www.codereckons.com/articles/65cbc0511318c3d21078737b>
>
>
> --
> SG7 mailing list
> SG7_at_[hidden] <mailto:SG7_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
> <https://lists.isocpp.org/mailman/listinfo.cgi/sg7>
>
> --
> SG7 mailing list
> SG7_at_[hidden] <mailto:SG7_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
> <https://lists.isocpp.org/mailman/listinfo.cgi/sg7>
>
> --
> SG7 mailing list
> SG7_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
>
>
>