Quick tangent:

> I’ve come to the conclusion that the syntax of certain metaprogramming
features should be sufficiently different from existing C++ notation,
perhaps even rising to the level of “unfamiliar”.

I'm curious if this is the position others on the committee are leaning
towards. Personally, I'm not sure I agree with this sentiment (although
many other aspects of the proposed seem like great features and additions
to the core language). In particular, we currently have at least 2
paradigms for authoring compile-time code: templates and constexpr. These
techniques are often at odds with each other and traversing the type
boundary can be somewhat awkward. Much of the advancement in C++17/20 has
served to blur the lines so that compile-time programming is accessible to
programmers without needing to resort to traditional template techniques,
many of which are decidedly cumbersome compared to their imperative
alternatives (fold expressions as an example, are a common source of
confusion, especially among beginners).

While C++ has long been known as a "federated language," where
practitioners are expected to learn 4 (?) paradigms of coding, should we
not tread carefully before creating a fifth, or potentially creating hybrid
programming models among those existing? Personally, it's hard not to find
compilers such as Zig (ref. comptime) and Circle compelling. The
programming model is uniform, and compile-time code and runtime-code are
easily shared (in the current status-quo, many algorithms are implemented
twice, once in runtime-land, once in compile-time land).

Summarizing, it's unclear to me that the benefits cited for composing an
"unfamiliar" syntax is worth it. Blurring the lines between compile time
and runtime code isn't intrinsically "bad" (in my opinion). In fact, this
is potentially a valuable feature to make code fungible in both compile and
runtime contexts.

On Mon, Oct 26, 2020 at 11:21 AM Andrew Sutton via SG7 <sg7_at_[hidden]>
wrote:

> To summarize my position: I support expanding `|# ... #|` (which also has
>> the problem that the generated identifier may not be determined to be
>> semantically valid until instantiation, or am I missing something?) to
>> allow string injections in as many contexts as possible, to help the user
>> to specify precisely what is dependent in their metafunctions, and
>> precisely what is not, up to and including full statements and declarations
>> should it ever be necessary.
>>
>
> Yes, the identifier splice operator is an explicit mechanism for
> creating unhygienic fragments. It's also the smallest possible facility
> that does so. There are some use cases where inventing new identifiers is
> necessary. That said, if we found ways to avoid requiring the operator, I
> would happily kill it. It's been the single hardest aspect of the
> implementation, IIRC.
>
> Just to be clear, I'm not strongly against a facility that turns strings
> into code. I think that making that the foundation of metaprogramming is
> the wrong choice for C++.
>
> Andrew
>
> --
> SG7 mailing list
> SG7_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
>