On Thursday, 10 July 2025 10:11:31 Pacific Daylight Time Jason McKesson via
Std-Proposals 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.

I'd expect to see this in code that uses reflection to create an externally-
visible serialisation format for C++ types that adhere to different style
guidelines on both sides. That would allow creating interfaces entirely in C+
+, without the need to have a generator tool like Microsoft's midl. And it
would avoid the need to have a C++ parser, like moc.

That said, transforming may be a bad idea in itself. You may accidentally
cause identifier collision if the transformation is not bijective, which
includes the case where the source contains an identifier that would not be
transformed at all.

I tried to do this for D-Bus & QtDBus back in 2006, because the guidelines for
D-Bus interfaces are to use IdentifiersWithCamelCaseCapitalFirst (probably
because then neither Qt/KDE nor glib/GNOME folks would be happy), because for
Qt all I'd need to do would be to lowercase the first letter and remove a "get"
prefix. Note how this is not a reversible transformation: it isn't clear when a
"Get" prefix needs to be added. This didn't last long and the result is that
you can tell when a D-Bus interface is KDE-specific (starts with lowercase
letters) or not.

Better than this would be to have an annotation that explicitly says what the
external serialisation name should be. So long as attributes can be reflected,
this is doable and would not require Unicode transformations.

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

Which is a point in favour of having those in the standard, if they need to be
constexpr at all, because then they can be implemented by an intrinsic
supplied by the compiler.

However, a code generation tool will probably be even faster.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Platform & System Engineering