-
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
Add MAX_UTF{8, 16}_LEN
constants
#98198
Conversation
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
(rust-highfive has picked a reviewer for you, use r? to override) |
This comment has been minimized.
This comment has been minimized.
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.
Changes the wording (somewhat based on that of char::len_{utf8,utf16}
), adds intra-doc links to char::encode_{utf8,utf16}
, and adds the "Use char::*
instead" sentences from #95566.
Co-authored-by: yvt <[email protected]>
Co-authored-by: yvt <[email protected]>
Co-authored-by: yvt <[email protected]>
Co-authored-by: yvt <[email protected]>
@@ -45,6 +45,16 @@ impl char { | |||
#[stable(feature = "assoc_char_consts", since = "1.52.0")] | |||
pub const UNICODE_VERSION: (u8, u8, u8) = crate::unicode::UNICODE_VERSION; | |||
|
|||
/// The maximum number of bytes required to [encode](char::encode_utf8) a | |||
/// `char` in UTF-8. | |||
#[stable(feature = "max_len", since = "1.63.0")] |
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.
I think these should go in unstable
with a tracking issue, no?
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.
I could but i thought since these were constants that replaced literal values we could directly stabilise them. I'm fine with adding unstable feature if that's the way to go
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.
There's basically three possible ways forward:
- This is an internal code readability change, so the consts are
pub(crate)
and it goes in with aT-libs
review. - This is a new API going in unstable, so it can go in with just a review on a "seems reasonable" basis.
- This goes in insta-stable, at which point is needs a full
T-libs-api
FCP.
Basically we only do 3 if forced (because some things can't go in unstable). So please make it unstable with a tracking issue, and then it can just be approved. (Consider also doing some commit squashing.)
/// The maximum number of bytes required to [encode](char::encode_utf8) a | ||
/// `char` in UTF-8. Use [`char::MAX_UTF8_LEN`] instead. | ||
#[stable(feature = "max_len", since = "1.63.0")] | ||
pub const MAX_UTF8_LEN: usize = char::MAX_UTF8_LEN; |
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.
pondering: are the module-level constants still desirable, now that we can have type-associated ones? It's unclear to me how to apply precedent from #68490 here -- the char
module certainly can't go away. But if the doc comment on this constant says not to use it, why add it?
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.
yeh i didn't think of type-associated ones, will change it to that
☔ The latest upstream changes (presumably #98190) made this pull request unmergeable. Please resolve the merge conflicts. |
@Dylan-DPC FYI: when a PR is ready for review, send a message containing |
closing this for the time being. will create a new PR with the changes when I get to it |
Closes #45795
Adds two constants for better readability.