-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify documentation on char::MAX #93392
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @scottmcm (or someone else) soon. Please see the contribution instructions for more information. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I think part of the problem is that this is the wrong place to be having a conversation about USVs/UCPs. How about just removing that from the documentation of this const
, since it's already there at the top of the documentation for char
https://doc.rust-lang.org/std/primitive.char.html?
Here's a first stab towards that direction, feel free to take directly or make your own:
/// The highest possible value a `char` can have, `'\u{10FFFF}'`.
///
/// # Examples
///
/// ```
/// # fn something_which_returns_char() -> char { 'a' }
/// let c: char = something_which_returns_char();
/// assert_eq!(c.max(char::MAX), char::MAX);
///
/// let value_after_max = char::MAX as u32 + 1;
/// assert_eq!(char::from_u32(value_after_max), None);
/// ```
And then maybe another PR could refactor the documentation on the primitive to have more about USV vs UCP vs grapheme vs whatever, as well as mention validity invariants, exhaustive matching on char
, ...
It's an unusual constant because for all numeric types, all values in the range
I like your examples although I would phrase the first assertion as |
I just think it's better to have that be a section on
Good point; that's much better. |
I've updated the documentation pretty much as in your version, I'll make a new PR for the documentation directly on |
Thanks for making these PRs! @bors r+ rollup=always |
📌 Commit 9aaf52b has been approved by |
…askrgr Rollup of 8 pull requests Successful merges: - rust-lang#90277 (Improve terminology around "after typeck") - rust-lang#92918 (Allow eliding GATs in expression position) - rust-lang#93039 (Don't suggest inaccessible fields) - rust-lang#93155 (Switch pretty printer to block-based indentation) - rust-lang#93214 (Respect doc(hidden) when suggesting available fields) - rust-lang#93347 (Make `char::DecodeUtf16::size_hist` more precise) - rust-lang#93392 (Clarify documentation on char::MAX) - rust-lang#93444 (Fix some CSS warnings and errors from VS Code) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Document valid values of the char type As discussed at rust-lang#93392, the current documentation on what constitutes a valid char isn't very detailed and is partly on the MAX constant rather than the type itself. This PR expands on that information, stating the actual numerical range, giving examples of what won't work, and also mentions how a `char` might be a valid USV but still not be a defined character (terminology checked against [Unicode 14.0, table 2-3](https://www.unicode.org/versions/Unicode14.0.0/ch02.pdf#M9.61673.TableTitle.Table.22.Types.of.Code.Points)).
Document valid values of the char type As discussed at rust-lang#93392, the current documentation on what constitutes a valid char isn't very detailed and is partly on the MAX constant rather than the type itself. This PR expands on that information, stating the actual numerical range, giving examples of what won't work, and also mentions how a `char` might be a valid USV but still not be a defined character (terminology checked against [Unicode 14.0, table 2-3](https://www.unicode.org/versions/Unicode14.0.0/ch02.pdf#M9.61673.TableTitle.Table.22.Types.of.Code.Points)).
As mentioned in #91836 (comment), the documentation on
char::MAX
is not quite correct – USVs are not "only ones within a certain range", they are code points outside a certain range. I have corrected this and given the actual numbers as there is no reason to hide them.