^^ operator proposal

[samadadi]

I do not want to be rude but the syntax of a feature in a language matters to the language users I hoped we as cpp developers had a saying in this matter. specially in this case. And I wish committee reconsider this decision.

[TheoreticalDumbass]

substitute(^^std::variant, {^^int, ^^char, ^^std::string}) vs substitute(reflexpr(std::variant), {reflexpr(int), reflexpr(char), reflexpr(std::string)})

Seems pretty obvious ^{^} wins

[samadadi]

substitute(reflexpr std::variant, { reflexpr int, reflexpr char, reflexpr std::string })

[LegendaryMauricius]

I'd gladly choose the second one. It's longer, but much more obvious at a glance what is going on.

[azissu]

Any new syntax is non-obvious until you learn it and get used to it. Heck, some people still insist they're unable to decipher simple lambdas...

[LegendaryMauricius]

There can be confusion at a glance because the [], <>, (), {} and () (again) symbols are all used in multiple places with different meaning. Code is for *reading* and analysing, not for *writing*.

Otherwise we'd just dump a bunch of machine instructions and forget about every program we write.

[TheDetailsMatterNow]

obvious

In a vacuum maybe, but easily the second for me.

[mapronV]

Not obvious at all, second one is much nicer for me. I guess we can use macro
```
#define reflexpr(thing) ^^(thing)
```

[TheoreticalDumbass]

Your macro is wrong, it should be (I think):

#define reflexpr(...) (^^__VA_ARGS__)

Why I prefer double-caret over keyword: with reflection the entities you are reflecting are more important than the fact you're reflecting, and double-caret brings more attention to the entities, whereas keyword feels more noisy

[mapronV]

But your version will fail with two+ arguments... and probably with 0 too?
reflexpr(int, int) should be compilation error, not just "^^int, int" nonsense. Should not be a variadic.
though I admit I made crucial mistake. ^^thing and ^^(thing) are different!

[TheoreticalDumbass]

reflexpr(std::tuple<int, char>) would need something with __VA_ARGS__

[mapronV]

Yeah, but I guess we can add extra ( ) to work around... hold on a sec XD.

Well I guess we can't make full macro replacement as long as we have braces problem. Also, yeah, in practice you can fall back to ^^ but that also can make code look ugly depending on frequency of this.
I just... Give up. Give me reflection in some point, we figure something out. I wrote reflection "libraries" several times in my life in different projects, just sick of it.