On Wed, Apr 7, 2021 at 1:42 PM David Vandevoorde <daveed_at_[hidden]> wrote:

> > On Apr 7, 2021, at 10:15 AM, René Ferdinand Rivera Morell via Ext <
> ext_at_[hidden]> 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