Some not-very-carefully-considered thoughts:

1. I like the ^ operator, pointing upward is properly suggestive of reflection.
2. I would probably prefer the inverse “splice” operation to then also be a unary operator (an alternative which is discussed at the bottom of the paper). Not only does having them both be unary ops make their inverse relationship clearer, but the “[: :]” is a bit too clumsy for me, have to press and release shift too many times, and so many dots in there it clutters things up a bit visually.

In particular I would suggest $ as the inverse of ^; that visually says to me it is "cashing in” a higher-order/meta object, bringing the ^ back down to earth.

Importantly, you could also allow usage of parens with both operators for clarity/visually “enclosing” the expressions for users that want or need it; e.g.

```
namespace detail {
  auto srefl = ^S;
  auto innerRefl = ^(S::Inner);
}
using InnerAlias = typename $(detail::srefl)::Inner;
```

By the way — what does reflecting an alias do? Does it fetch the properties of the canonical type, or the properties of the alias itself? If you wanted to support both, perhaps we could use the parens after ^ to distinguish:
```
auto innerAliasRefl = ^(InnerAlias); // reflects the canonical type
auto innerRefl = ^InnerAlias; //reflects the alias
static_assert(std::is_same_v<$innerRefl, $(meta::desugar_alias(innerAliasRefl))>);
```

3. All the dots in the pack expansion stuff are pretty hard to read; I think more consideration/justification/explanation of that syntax is warranted. In particular I don’t understand the need to “nominate” a pack for expansion; I see the footnote about some compilers needing to be alerted beforehand about whether or not to keep the tokens that follow, but I don’t understand that, nor have much sympathy for those compilers :) — better the compilers deal with confusion than the user.


> On Feb 15, 2021, at 4:25 PM, Hana Dusíková via SG7 <sg7_at_[hidden]> wrote:
>
> Hi,
>
> Andrew, Wyatt, and Daveed kindly finished the paper which was mentioned during last SG7 session and because the next SG7 meeting is next week I would like all of you to read the paper and send feedback to SG7 mailing list, so we have as much of information as possible.
>
> The paper is here: https://isocpp.org/files/papers/P2320R0.pdf <https://isocpp.org/files/papers/P2320R0.pdf> and it will be part of the next mailing.
>
> Hana
> --
> SG7 mailing list
> SG7_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7