r? @m-ou-se

(rustbot has picked a reviewer for you, use r? to override)

☔ The latest upstream changes (presumably #121295) made this pull request unmergeable. Please resolve the merge conflicts.

In the tracking issue, please include a mention that when stabilizing this we should adjust the documentation of https://doc.rust-lang.org/std/primitive.char.html#method.encode_utf8 to use it.

We briefly discussed this in the libs-api meeting and are happy to add these as unstable.
Please open a tracking issue and use that in the #[unstable] attributes. Thanks!

Tracking issue created. Will finish the remaining things later today.

@rustbot ready

☔ The latest upstream changes (presumably #116113) made this pull request unmergeable. Please resolve the merge conflicts.

Small question: why are these constants in the char module instead of being associated constants on the char type? The initial proposal is from 2017 when presumably this wasn't possible, but now that it is, we should probably make them associated constants instead to avoid having to duplicate across multiple modules.

Small question: why are these constants in the char module instead of being associated constants on the char type? The initial proposal is from 2017 when presumably this wasn't possible, but now that it is, we should probably make them associated constants instead to avoid having to duplicate across multiple modules.

From what I can tell, in this PR they are added as associated constants on char-the-type and then also reexported in char-the-module.

Oh, I completely missed that point. I personally wouldn't add module exports since that way there's just one way to access them.

We've also been deprecating the module equivalents of associated consts in a bunch of places, and so adding a new one doesn't make much sense.

☔ The latest upstream changes (presumably #130165) made this pull request unmergeable. Please resolve the merge conflicts.

Observation: we still don't support importing associated constants in order to use them unqualified, and these seem like the kinds of things people might want to import and use unqualified.

Until we support importing associated constants, I think we should add these as both. We can always deprecate the module constants in the future when we do add that support.

Recording an observation from a discussion in a meeting: I found MAX_LEN_UTF16 misleading, as I would have expected "number of bytes" rather than "number of 16-bit words".

This isn't a blocking objection, on the basis that anytime I'm using UTF-16 I'm already having a bad time, so this doesn't make it that much worse. I just hope that nobody ever uses this to size e.g. a buffer for a read call and ends up with the wrong buffer length.