I’m not familiar with this committee/community, and haven’t kept track of the latest papers or what has already been committed to, but I did some experimental work along these lines awhile back and so will offer some thoughts, if only to offer a fresh perspective, play devil’s advocate, and maybe provide some entry points for discussion.

Andrew’s paper considers metaprogramming holistically. To frame the discussion, I believe there are three holistic questions to answer:
1. What kinds of things should be returned by reflexpr(…)?
2. What kinds of things should be returned by reflection queries? (And what side effects of queries are allowable?)
3. What kinds of things can be injected, i.e. compiled into the context enclosing a `consteval {…}` metaprogram?

A fourth, which I won’t address, is what syntactic sugar should be offered atop this base functionality (e.g. metaclasses etc.).

Taking them in reverse order:

# 3
I think only strings should be injectible. Get rid of fragments — they are a source of needless complexity. IIUC, Andrew proposes the ability to inject arbitary code strings via `|# … #|` syntax. E.g. `consteval { |# "private: int i = 42;" #| }` would inject a private `i` into the enclosing class context (and result in a parse error if not in a class).

That is great! But it also means we don’t need fragments anymore. Any fragment can be represented as a string after all. If you get rid of fragments, and force injection to always occur via strings, you can get rid of much of the proposed, frankly impenetrable fragment syntax.

# 2
Another source of possibly-needless complexity is that certain reflection queries return packs, e.g. `meta::members_of(x)`. This requires user to use a special `template for(…)`, etc. That is unfortunate. Why can’t `meta::members_of(x)` (or `reflexpr(x)->members()` in an object-oriented design) returned an ordinary range object, which can be iterated over via an ordinary for loop? I know there are difficult implementation issues to address with consteval iteration — but is that the sole reason for returning packs and forcing users to use `template for` etc?

# 1
This probably is too big a can of worms to open but FWIW I favor an object oriented hierarchy, rather than `meta::info`. I.e. `reflexpr(somefunc)` should return a `meta::FunctionDecl` object, which is also a `meta::NamedDecl` etc. We are writing C++, not C, and an object oriented reflection hierarchy would be more user-friendly.

IIUC the only justification given for `meta::info`, instead of object oriented, is that the former is said to be more "efficient" than the latter, in that it results in marginally lower build times.

First, I don’t understand why this is necessarily the case. If base method calls are considerably more costly to constant-evaluate than external function calls (excepting maybe when they are initially parsed, and one-time extra lookup costs are incurred), that seems to indicate constant evaluation is inefficiently implemented by the compiler. If so, that problem should be addressed, not built around. It would be helpful if someone could explain or point me to an explanation where I’m off base here.

But even setting that aside: shouldn’t the complexities and inadequacies of a non-object-oriented design that the programmer must navigate in writing their metaprograms count toward any consideration of the "build times"?


> Date: Fri, 23 Oct 2020 10:22:37 +0200
> From: Hana Dus?kov? <hanicka_at_[hidden]>
> To: sg7_at_[hidden]
> Cc: Evolution Working Group mailing list <ext_at_[hidden]>,
> lib-ext_at_[hidden]
> Subject: [SG7] Metaprogramming
> Message-ID: <271FE379-4ECA-425F-9BEC-84CFFDD1883D_at_[hidden]>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi!
>
> I guess you all notices pretty big paper from Andrew in October mailing: http://open-std.org/JTC1/SC22/WG21/docs/papers/2020/p2237r0.pdf <http://open-std.org/JTC1/SC22/WG21/docs/papers/2020/p2237r0.pdf>
>
> I'm going to schedule a SG7 meeting in 2 or 3 weeks, to give everyone who wants to attend to read it in detail.
>
> I'm also starting this thread (reply only to SG7 mailing list please), where I would like to keep discussion and give Andrew questions you would like him to answer.
>
> Due the amount and number of changes the paper propose there is a chance we will have more than one meeting. Don't expect any voting during first one. I would like to focus us on informed discussion only.
>
> Have a nice weekend!
>
> Hana
>
>