>
> 1 - May the ellipsis be inside the splice [: ... R:] for reflexive R
> expansion ?
>

No. Splicing is not a context where expansion can happen. That is, this
would be ill-formed

[: A, B, C :] // error: nope



> 2 - Can we reflect template arguments ?
>
> template <typename T>
> consteval auto ref_helper() {
> return ^T; // reflect the parameter T ? or the type that was
> passed as argument T in the instantiation helper<T>
> }
>

Yes. See P1240, which should be required reading for this paper.




> 3 - Can we call a function inside a splice with template dependent
> parameters ?
>
> template<typename U>
> struct X {
> [: ref_helper<typename U::inner>() :] u; // dependent name
> };
>
> struct I { using inner = int; };
>
> X<I> x;
> x.u = 10; // x.u is int ?
>

Yes, the operand of a splice is a constant-exprssion. This is in the paper.



> 3 - Can we splice recurrently ?
>
> auto W = ^Z;
> class x {
> [: ref_helper< [: W :] >() :] u; // -> expands to [: helper< Z
> >() :] then, to Z
> };
>

Yes. The inner splice is applied first, then the outer splice. Here, W
needs to be declared constexpr.



> 4 - Any consideration for a unary suffix operator ^ for splicing ? Just
> like your example 5.3.3 we could have a valid (and cute) ^int^, (^0^),
> ^()[]{}^ constructs
>

Yes. And postfix ^ causes all sorts of problems---like breaking every
program containing an exclusive-or expression (x ^ y).

Even if we didn't have that problem, the precedence is all wrong. ^int^
parses as ^[int^], meaning you're splicing int and then taking its
reflections, which isn't particularly meaningful.

What's worse, is that we could never relax the requirements of using
keywords to guide the parse. For example, in this paper, we can omit
typename in contexts where the splice can only be a type: So with postfix
spllce:

struct X : some_complex_expression^ { ... }

This would mean that we need to adjust the grammar and our parsers to
differentiate between types and expressions in all those contexts. You will
not find much support for this design in EWG.


5 - I believe that, If we open the gate to $, even other SG´s will claim
> it, just saying...
>

I don't know if this is an argument for or against using $.



> 6 - Attributes ?
> I mean... user defined/turin complete/dependent/reflexive/spliceble
> attributes ?
>

There's been some discussion about reflecting attributes, but not splicing.
Corentin had a paper about uesr-defined attributes (I forget the number),
but the issue is revisited and elaborated on in P2237 (which should also be
required reading).

I think it's reasonable to kick that can down the road a bit.

Andrew