-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
Standardize on either 'upper_case' or 'uppercase' #24536
Comments
Naming conventions are covered by https://github.com/rust-lang/rfcs/blob/master/text/0430-finalizing-naming-conventions.md, |
Oh, you literally mean one or two words for 'upper case,' not when things should be upper vs lower case. Sorry about that! |
/cc @aturon |
I don’t know if renaming the attribute is considered a breaking change. |
* Add “complex” mappings to `char::to_lowercase` and `char::to_uppercase`, making them yield sometimes more than on `char`: #25800. `str::to_lowercase` and `str::to_uppercase` are affected as well. * Add `char::to_titlecase`, since it’s the same algorithm (just different data). However this does **not** add `str::to_titlecase`, as that would require UAX#29 Unicode Text Segmentation which we decided not to include in of `std`: rust-lang/rfcs#1054 I made `char::to_titlecase` immediately `#[stable]`, since it’s so similar to `char::to_uppercase` that’s already stable. Let me know if it should be `#[unstable]` for a while. * Add a special case for upper-case Sigma in word-final position in `str::to_lowercase`: #26035. This is the only language-independent conditional mapping currently in `SpecialCasing.txt`. * Stabilize `str::to_lowercase` and `str::to_uppercase`. The `&self -> String` on `str` signature seems straightforward enough, and the only relevant issue I’ve found is #24536 about naming. But `char` already has stable methods with the same name, and deprecating them for a rename doesn’t seem worth it. r? @alexcrichton
Is this issue still relevant? I think the warning mentioned is stabilized and changing it would break existing code that uses it. |
Yes, I don't think that this particular thing is actionable nowadays. Such is life! Hopefully these are the worst things we regret in the future :) |
The standard library uses names like
to_uppercase
, while there's a warning with the namenon_upper_case_globals
. One of these should be changed, for consistency. (There may be other instances of this inconsistent naming - I haven't checked.)It would be a breaking change to change functions like
to_ascii_uppercase
, but renamingnon_upper_case_globals
tonon_uppercase_globals
should only result in more warnings, so it doesn't seem like a breaking change.The text was updated successfully, but these errors were encountered: