Skip to content
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

Closed
nstoddard opened this issue Apr 17, 2015 · 6 comments
Closed

Standardize on either 'upper_case' or 'uppercase' #24536

nstoddard opened this issue Apr 17, 2015 · 6 comments

Comments

@nstoddard
Copy link

The standard library uses names like to_uppercase, while there's a warning with the name non_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 renaming non_upper_case_globals to non_uppercase_globals should only result in more warnings, so it doesn't seem like a breaking change.

@steveklabnik
Copy link
Member

@steveklabnik
Copy link
Member

Oh, you literally mean one or two words for 'upper case,' not when things should be upper vs lower case. Sorry about that!

@steveklabnik
Copy link
Member

/cc @aturon

@SimonSapin
Copy link
Contributor

char::to_uppercase is #[stable] and so can not be removed in 1.x. Deprecating it in favor of renamed method doesn’t seem worth it.

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
@soderstroff
Copy link
Contributor

Is this issue still relevant? I think the warning mentioned is stabilized and changing it would break existing code that uses it.

@steveklabnik
Copy link
Member

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants