Update to_uppercase docs to avoid ß->SS example

[guilhermeljs]

Fixes #150888

Updates the to_uppercase documentation examples to avoid relying on the ß → "SS" mapping and instead uses a stable multi-character case-mapping example ('ffi' → "FFI").

Note: the example uses U+FB03 (LATIN SMALL LIGATURE FFI), not the ASCII string "ffi".

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[Noratrieb]

Maybe it would make sense to leave a comment explaining that this is a single codepoint? It might be a bit confusing otherwise, as people are likely to not know that these exist (I didn't)

[workingjubilee]

Hh... hmm. Would it be better to move this comment to a Rust comment inside the example code block so that it's directly visible in-context and likely to be copied with it?

[guilhermeljs]

Hh... hmm. Would it be better to move this comment to a Rust comment inside the example code block so that it's directly visible in-context and likely to be copied with it?

@workingjubilee

If we move the note into a Rust comment inside the first example, wouldn't it seem local to that specific snippet? Because here we have three snippets that demonstrate the same semantic fact ('ffi' to "FFI"), just through different APIs (iteration vs println! vs assert). Putting the explanation in only one of them wouldn't make the other appear to lack the key context?, and I feel like duplicating the same comment in all of them would introduce redundancy. (maybe i'm overthinking it, and you have a great point about being likely to be copied with it)

I think keeping it as an introduction note makes it clear that it applies to the entire Examples section. What do you think?

[workingjubilee]

Ah, my eyes glazed over and failed to fully process the rest of the diff, it seems!

...Yyyyes, I think it's either "once" or "repeated per-instance", and at that point I am less sure of either choice as I think there is still merit of keeping the note close but redundancy is, well, redundancy.

[workingjubilee]

I was trying to think of a ligature that would be less "what? that's one codepoint?" to readers, because of being more commonly seen, but unfortunately the best example I can think of, 'æ' (still uncommon but everyone sees it due to its popular usage in various creative and "creative" wordmarks) has its big sister 'Æ'.

[workingjubilee]

( Also that's because it isn't a ligature exactly, except it kinda is, but it also is a Proper Letter, "æsh", retained like þ (thorn) and others. )

[guilhermeljs]

I was trying to think of a ligature that would be less "what? that's one codepoint?" to readers, because of being more commonly seen, but unfortunately the best example I can think of, 'æ' (still uncommon but everyone sees it due to its popular usage in various creative and "creative" wordmarks) has its big sister 'Æ'.

@workingjubilee
I also looked for another ligature and found a good candidate: "ſt" (U+FB05). It maps to "ST" in uppercase, which is the property the docs tries to demonstrate (The example of a single Unicode character mapping to multiple characters when in uppercase)

What do you think?

[guilhermeljs]

Also, it's slightly better than the previous ffi ligature. (But in font-rendering it looks like "ft" (FT))

[workingjubilee]

oh, long S. sure!

[guilhermeljs]

I was trying to think of a ligature that would be less "what? that's one codepoint?" to readers, because of being more commonly seen, but unfortunately the best example I can think of, 'æ' (still uncommon but everyone sees it due to its popular usage in various creative and "creative" wordmarks) has its big sister 'Æ'.

Hmmm.. Would the æ code point work in this context? Because it doesn't map to multiple characters when in uppercase ('Æ' is still only one code point), i think the previous example “ß” was used to demonstrate this property

[guilhermeljs]

So, after some chatting with @workingjubilee on Zulip, I chose to go with the "ſt" ligature because I feel it's less confusing in font-rendering than the "ffi" ligature (which looks exactly like the string "ffi", here using Firefox and Github I can't even tell the difference). The introductory explanation note will be kept as well to make things clearer for readers

[workingjubilee]

Hmmm.. Would the æ code point work in this context? Because it doesn't map to multiple characters when in uppercase ('Æ' is still only one code point), i think the previous example “ß” was used to demonstrate this property

for clarity: it would not, and my lamentation was basically "alas, any ligature that is used enough becomes considered a 'proper letter' which then means it is given a majuscule variant even if it didn't have one before". the Eszett is counted here, as it is also a ligature based on long S and Z.

As I think this is the most distinctive variation we're getting:

@bors r=Noratrieb,workingjubilee

[rust-bors]

📌 Commit 6b5a1a5 has been approved by Noratrieb,workingjubilee

It is now in the queue for this repository.