Date: Wed, 9 Jul 2025 10:51:53 -0400
On Wed, Jul 9, 2025 at 10:30 AM Tiago Freire via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> > Part of the reason there's so many diverging implementations of "case insensitivity" is the lack of standardization. Here, the standard exists (Unicode). It is freely accessible, portable, and handles all of the edge cases we are discussing. We just need to implement it.
>
> Yes, but what I wanted to point is that a reason to want this feature is to deal with these interfaces, and these interfaces will not change because this feature is provided.
> The argument being providing this feature in order to use these interfaces is misguided as it will not provide the correct "case-insensitive" handling. It sounds similar enough for people to confuse it and shoot themselves in the foot.
> I.e. not a valid reason.
>
>
> > I write a command-line applications at my day job. Sometimes I want user input/arguments to be case-insensitive because it's less stuff to remember. It's not a word processor or anything complex.
>
> Which is a valid although unusual in the command line processing space.
> And given you only have to deal with a small subset of words you need to understand, and as you have stated, a small subset of characters in the ASCII range is a good enough implementation to cover all cases.
> And then again you only have to do that conversion at the moment the user inputs their text... not a compile time thing. So, no constexpr required.
>
> Hence why I'm skeptical of the need for such a constexpr facility. Runtime conversion maybe, but constexpr? If there is really a use case for it, I'm yet to find one.
This discussion seems to have drifted more into whether this Unicode
feature should be implemented or not, not so much the "constexpr"
part.
Indeed, I'm not sure that any Unicode processing *needs* to be
`constexpr` even if it could be. Maybe if you're using `#embed` to
include a UTF-8 file as a byte sequence and need to do some Unicode
processing on it to generate some static array?
<std-proposals_at_[hidden]> wrote:
>
> > Part of the reason there's so many diverging implementations of "case insensitivity" is the lack of standardization. Here, the standard exists (Unicode). It is freely accessible, portable, and handles all of the edge cases we are discussing. We just need to implement it.
>
> Yes, but what I wanted to point is that a reason to want this feature is to deal with these interfaces, and these interfaces will not change because this feature is provided.
> The argument being providing this feature in order to use these interfaces is misguided as it will not provide the correct "case-insensitive" handling. It sounds similar enough for people to confuse it and shoot themselves in the foot.
> I.e. not a valid reason.
>
>
> > I write a command-line applications at my day job. Sometimes I want user input/arguments to be case-insensitive because it's less stuff to remember. It's not a word processor or anything complex.
>
> Which is a valid although unusual in the command line processing space.
> And given you only have to deal with a small subset of words you need to understand, and as you have stated, a small subset of characters in the ASCII range is a good enough implementation to cover all cases.
> And then again you only have to do that conversion at the moment the user inputs their text... not a compile time thing. So, no constexpr required.
>
> Hence why I'm skeptical of the need for such a constexpr facility. Runtime conversion maybe, but constexpr? If there is really a use case for it, I'm yet to find one.
This discussion seems to have drifted more into whether this Unicode
feature should be implemented or not, not so much the "constexpr"
part.
Indeed, I'm not sure that any Unicode processing *needs* to be
`constexpr` even if it could be. Maybe if you're using `#embed` to
include a UTF-8 file as a byte sequence and need to do some Unicode
processing on it to generate some static array?
Received on 2025-07-09 14:52:05