On Wed, Apr 7, 2021 at 1:42 PM David Vandevoorde <daveed@edg.com> wrote:
> On Apr 7, 2021, at 10:15 AM, René Ferdinand Rivera Morell via Ext <ext@lists.isocpp.org> wrote:
>
> First, sorry for the late reply, I blame slow paper reading :-) Can someone clarify something that I must be missing about the proposed splice syntax. Is there rationale for why one needs any splice syntax at all given that the reflections are strongly typed? At a, probably very ignorant, high level it appears to me that you could just have the reflected names without the "[:R:]". What am I missing?

There are at least two reasons.  First, in non-expression contexts it allows us to know that we should switch to an expression context.  E.g.:

        struct D1
           : X::B {  // Currently, “X::B” is assumed not to be an expression here.
           …
        };

and the parallel:

        struct D2
           : [: X::R :] {  // The operand of splicers are expressions.  So X::R can be assumed to be an expression.
          …
        };

Makes sense now :-) Although it would be possible to not assume it's not an expression and use the context. Which is what I was alluding to from my questions.
 
Second, reflection-expression vs. spliced-expression disambiguation.  Consider:

        consteval info f() { … }
        constexpr auto r1 = f();
        constexpr auto f2 = [: f() :];

Suppose f() returns a reflection of an expression. Clear r1 and r2 mean different things and one shouldn’t be assumed to be equivalent to the other (r1 is initialized with the expression reflection itself; r2 is initialized with the expression reflected by that expression reflection (which itself may or may not be an expression reflection, or some other reflection, etc.).

But that makes it clear why it's needed. No contextual way to disambiguate that without the splice operation. Thanks!

--
-- René Ferdinand Rivera Morell
-- Don't Assume Anything  -- No Supone Nada
-- Robot Dreams - http://robot-dreams.net