Hi everyone,

I'd like to have a discussion about being able to inject a name in a
postfix injection and having a type for names that is not `string_view`
(ideally I would have asked for feedback on those ideas in Wroclaw but I
was not there).

I've talked about the benefits in P3435, but I think the most important one
is the following :

It enables a simple and efficient implementation of tuple/variant get.
Given a member data with some members `m0...mN`, `get` becomes
`return data.[: cat("m", N) :]`
This is a string concatenation and a single lookup in a hashtable. Compare
this to what P2296 is doing : we're walking the entire fields range for
each get (quadratic complexity) and constructing a whole vector to pick
just one element.
You could argue that this could be fixed by having a
`nth_nonstatic_data_member_of` function, but not quite : at least in Clang,
the underlying range containing the fields is a filtered linked list, that
we have to traverse each time, which gives us quadratic complexity.

 Arguably, this does not requires a type for names. A postfix injection
could be accepting a range of char. However a range of char is a really
poor representation choice for operator names and conversion names.

Also, a builtin type for name could be passed as template arguments just
like `std::meta::info`.
I know the problem expanding the set of structural types is an orthogonal
concern, but as AFAIK there is no proposal in the pipeline to address this,
it's wise to take into account this limitation over string or string_view.
As discussed in P3435, passing a name as template argument gives us the
possibility of "lifting" members or emulating Swift keypaths.

Perhaps this does not need to be in C++26 however I hope the door can be
left open to make this change later, and P2296 already use the name
`name_of` and `identifier_of`, which, if I may suggest, could be renamed
`string_name_of`/`string_identifier_of`.

Let me know what you think.
-JB