On Sat, Oct 24, 2020 at 11:11 AM David Rector <davrec_at_[hidden]> wrote:

> Richard the git I linked to below works but the source is a bit of a mess;
> to give you the broad strokes, these are the big changes that would be
> needed to parse string literals during constant evaluation, in case this
> were to be seriously considered:
>
> 1. The Parse and Sema libraries would need to be combined.
>
> That wouldn't be acceptable, but you could register a callback instead;
that's what we do for MSVC-compatibility-mode's delayed template parsing.

>
> 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.

> On Oct 24, 2020, at 1:35 PM, Ville Voutilainen <
> ville.voutilainen_at_[hidden]> wrote:
>
> On Sat, 24 Oct 2020 at 20:01, David Rector <davrec_at_[hidden]> wrote:
>
>
>
>
> On Oct 24, 2020, at 12:34 PM, Ville Voutilainen <
> ville.voutilainen_at_[hidden]> wrote:
>
> On Sat, 24 Oct 2020 at 19:17, David Rector via SG7 <sg7_at_[hidden]>
> wrote:
>
> # 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 doesn't seem to be correct. The paper says that a |# ... #| is an
> identifier splice, not an arbitrary string.
>
> I am under the impression that building injected code with just
> strings or with just tokens is rather horrible
> for implementations? For syntax validation and semantic analysis, most
> likely. Token-soup-injection
> as a possibility sure made our clang friends balk in Toronto.
>
>
> What’s so horrible about the implementation? Here’s an old clang
> implementation, scroll down to the "metaparsing" part for examples:
>
> https://github.com/drec357/clang-meta
>
>
> Perhaps Mr. Smith could illuminate us.
>
>
>