On Thu, Jul 10, 2025 at 12:05 PM Sebastian Wittmeier via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Is it really so far-fetched?

Well, your specific example was just terrible from a UX perspective.
Using code to create invisible identifiers that you have to read
generative metaprogramming code to know what the API actually is is
not a good idea if you want users to know what's going on. Converting
CamelCase to lower_case is such a trivial thing that using generative
metaprogramming to do it makes the code harder to work with, not
easier.

> - reflection-based metaprogramming is coming into C++
>
> - the reflection will also read user code (from the view of a library using reflection on user-provided code or classes)
>
> - it is possible and supported to use unicode in C++ identifiers
>
> - we probably need all kind of constexpr functions supporting string processing at compile-time

And if such things are shown to have utility, we can address them
then. Right now, we should just focus on getting good Unicode support.
Whether a particular Unicode function should be `constexpr` is a
question that can be addressed on a case-by-case basis.

You can't take `constexpr` back later. But you can add `constexpr`
later. So the safest move is to just focus on the functionality and
deal with the `constexpr` question as it comes up.

It should also be noted that `constexpr` Unicode processing is not
*free*. Those tables are not tiny and compile-time code is not nearly
as fast as runtime code. Running through those tables is not going to
be quick, especially for more complex operations like Unicode
normalization.