On Wed, Jul 9, 2025 at 11:31 AM Sebastian Wittmeier via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Perhaps the ICU or parts of it should be integrated into the standard library?
>
>
>
> There are lots of cases (in the past or currently), where features were tested as a library first or successful libraries or at least their interfaces were incorporated into the standard. Why should it differ from linear algebra, dates and times and physical units?
>
>
>
> Text processing is a basic functionality.
>
>
>
> We want to do more and more at compile-time, make constexpr everything, even do metaprogramming. So of course it should work at constexpr time.

Do we really want that, though?

As has been pointed out, the core issue is that those tables *change*.
Some change more rarely than others, but they do change. This is not
like Pi, where the value is what it always has been forever; it's a
specification that receives upgrades.

If these tables must be available at compile-time, what is supposed to
happen if the implementation wants to update them? Is a user able to
specify which version of the Unicode standard to use, and if so, how
would that affect compile-time processing?

And from a personal perspective, the idea that *everything* should be
`constexpr` is just... fantasy. Things should be `constexpr` if there
is a legitimate, demonstrable need for them to be. Making everything
`constexpr` is the same kind of thinking that led to the fiasco with
making the Regex library a template library: suddenly, the ABI is
statically encoded into every program that uses it and thus can never
be changed without breaking everyone. So there's a whole class of
optimizations that can never be performed without an ABI break.

Let's not go down that road again. We cannot undo `constexpr`, so we
should first make sure the functionality is available in a good form.
After that, we can decide if being `constexpr` is reasonable and won't
cause problems.