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

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>
      }

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 ?

3 - Can we splice recurrently ?

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

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

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

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


BR
Cleiton

Em seg., 15 de fev. de 2021 às 22:21, Ville Voutilainen via SG7 <
sg7_at_[hidden]> escreveu:

> On Tue, 16 Feb 2021 at 03:00, Corentin <corentin.jabot_at_[hidden]> wrote:
> >> It would be unwise to make C++ a language that plays less well with
> >> its surrounding environment. Some of those
> >> tools support C++ as just one language out of many, and the
> >> plausibility of such tools just dropping C++ as
> >> a supported language isn't clear-cut to be a short-term concern. But,
> >> again, we are rehashing a discussion
> >> that has been had before, and there's no new information in it.
> >
> >
> > I would point out that java, c#, rust, php, perl, JavaScript, Swift, go,
> D and others use dollar signs, either as part of the grammar or in
> identifier. And dollar signs can appear in strings, so a tool that would
> use a single codepoint to do replacements is likely to be brittle and i
> would love to see evidence of such tool existing to such extent that
> claiming $ in C++ would be problematic.
> > Just one!
>
> Well, start looking, then. Ask Mr. Smith what tools he was talking
> about. Also check whether tools like velocity
> break, and in which ways, if C++ claims $. There are more tools that
> use dollars for markers, outside
> strings, so if we wish to use $ outside strings, it shouldn't be all
> that hard to test them with C++ that uses
> a hypothetical $ syntax. You don't even need a modified C++ compiler,
> just feed those tools C++ that uses
> $ for reflection purposes.
>
> Then tell us what you found.
>
> > Should we close design avenues because we cannot with certainty disprove
> their existence?
>
> No. We should stop wasting our time on repetitive discussions about
> whether we can grab $.
> But in case we wish to rehash that waste of time *again*, we should
> analyze its impact.
>
> We should of course analyze the impact of this proposal we're talking
> about, too. Any syntax that's ill-formed
> C++ today is possibly used by some wide-spread tool.
> --
> SG7 mailing list
> SG7_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
>