>
>
>> 1. Some additional code added to the Lexer/Preprocessor (nothing in
>> the hot path), similar to the functionality used to expand macros.
>> 2. Some additional logic needed to add "metaparsed" Decls into
>> template instantiations (setting up scopes etc.).
>> 3. There may be issues when the user calls macros in the code strings
>> (e.g. `__metaparse("int SOMEMACRO(foo) = 4")`) — I got crashes early on,
>> added checks and diagnostics to address them, but they were needed in a
>> number of strange spots so a more comprehensive consideration would be
>> warranted.
>> 4. Would be nice if diagnostics could point inside a string literal,
>> e.g.
>>
>> ```
>> __metaparse("int i = missspelling;");
>> ^ unknown identifier
>> ```
>>
>> It’s been awhile but I think that covers it.
>>
>
> I have no doubt that you can get simpler cases working this way. But the
> way we process source during parsing and during template instantiation are
> fundamentally different, so I'd expect lots of things to not work (for
> example, you won't be able to do lookups that find local variables when
> injecting into a function scope).
>
> But honestly, I don't think implementation complexity is the primary
> reason we shouldn't do this. I think the better reason is that such an
> approach is fundamentally distasteful and unhygienic in much the same way
> that macros are. You know what's worse than a vexing parse bug? A vexing
> parse bug caused by a compile-time program spitting out an ambiguous string
> of C++ code. Good metaprogramming is semantic, not based on what a string
> happens to mean when interpreted in a particular context.
>

Exactly this.

My work on injection (2015 or 16 I think) started using tokens, but moving
to strings is not a big jump. The implementation isn't really hard. What
killed that approach was the fact that names in the fragment/token
sequence/string are completely reinterpreted at the point that you inject
them. Those names that you thought referred to types suddenly don't when
injected. If you're lucky, you get compiler errors. If you're unlucky, you
can also get runtime bugs.

I spent a month or so trying to find ways to alleviate those problems, but
still using macros and ended up with a weird kind-of-like-C++ grammar that
mostly worked, but only in trivial cases. So, I looked at using templates
as a basis for injection. The underlying concepts aren't too fundamentally
different.

Anyway, all of that "needless complexity" in fragments aims to provide a
strong guarantee that the code injected into a program has the meaning
intended when it was written. And actual users don't seem to have been
terribly burdened by the model.