On Tuesday, 8 July 2025 09:37:10 Pacific Daylight Time David Brown wrote:
> I am not suggesting that I would want to write code that only supported
> ASCII and Norwegian letters - that would be going back to the "good old
> days" of 8-bit code pages. I am saying that I do not need all of
> Unicode - but I /do/ want basic UTF-8 support. I might be interested in
> case-insensitive comparisons of words, and I'd like them to work for the
> languages which are realistic for the code I write and where it is used.
> But I don't want to spend significant development and testing time on
> the details of languages that are highly unlikely to be used.
[...]
> So yes, I would expect my programs to handle Polish letters in a name
> perfectly well. But I would not want to spend time and effort (in
> development or at run-time) worrying about how the specific Polish
> letters might change in capitalisation or case-folding in different
> circumstances - a single all-or-nothing reasonably accurate general
> Unicode function would be fine for a program that does not claim to
> support Polish.

This is what I am arguing against: just because you don't think you will need
this does not make it true. Your not testing the scenario is your choice,
either conscious or not. Maybe it will never be a problem for you, but my
experience with long-lived source bases is that they eventually turn up.

More importantly, I don't think the Standard needs to cater for that case,
especially not for constexpr support. The Standard should support the
near-100% use-case and because of that, I see no point in there being a third
option that is in-between the US-ASCII and the full support. An implementation
could be limited as such, because of validation and testing costs, but vendor-
imposed limitations are nothing new. If that works for your needs, great, you
may be able to pay your vendor less.

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