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. |
bors
added a commit
that referenced
this issue
Jun 9, 2015
* 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 :) |
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
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_globalstonon_uppercase_globalsshould only result in more warnings, so it doesn't seem like a breaking change.The text was updated successfully, but these errors were encountered: