Date: Mon, 26 Oct 2020 20:10:13 +0200
On Mon, 26 Oct 2020 at 19:58, Jeremy Ong via SG7 <sg7_at_[hidden]> wrote:
>
> 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.
The part you quoted says "of certain metaprogramming facilities". They
stand out, which is kinda nice when
you do normal compile-time computations interspersed with injections.
If the meta-bits blend in, it's a bit harder
to see where the different worlds are. Those different worlds are not
clashing, they blend in controlled ways.
The different-world-mixture in p2237 doesn't look alarming to me, but
then again, my experience in such
mixtures comes from Common Lisp, not Circle.
>
> 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.
The part you quoted says "of certain metaprogramming facilities". They
stand out, which is kinda nice when
you do normal compile-time computations interspersed with injections.
If the meta-bits blend in, it's a bit harder
to see where the different worlds are. Those different worlds are not
clashing, they blend in controlled ways.
The different-world-mixture in p2237 doesn't look alarming to me, but
then again, my experience in such
mixtures comes from Common Lisp, not Circle.
Received on 2020-10-26 13:10:26