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

Making f64::from_str case insensitive #48881

Closed
JohnBSmith opened this issue Mar 9, 2018 · 2 comments
Closed

Making f64::from_str case insensitive #48881

JohnBSmith opened this issue Mar 9, 2018 · 2 comments
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@JohnBSmith
Copy link

Consider making f64::from_str(src: &str) -> Result<f64, ParseFloatError> case insensitive due to the following reasons:

  1. people may see infinity as a constant and write "INF" or "Inf"
  2. f64::INFINITY is all upper case
  3. f64::NAN is all upper case
  4. is_nan is all lower case
  5. e in "12e3" is case insensitive, so it seems to be inconsequent
  6. "NaN" is camel case, but "inf" is lower case, which seems to be a little bit inconsistent
  7. to_ascii_lowercase is slow and will not be of help as "NaN" is mixed case
  8. to_ascii_uppercase is slow and will not be of help as "NaN" is mixed case
  9. a hypotetical function to_standard_form(src: &str, dest: &mut str) -> Result<(), ParseFloatError> is not possible as str cannot be mutable

So far, only "inf" and "NaN" are allowed.

Cons:

  • slows parsers down by a minimal amount
  • increases code size by a minimal amount
@kennytm kennytm added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. C-feature-request Category: A feature request, i.e: not implemented / a PR. labels Mar 9, 2018
@clarfonthey
Copy link
Contributor

Note that you can obtain &mut str from a String or &mut [u8]. Nonetheless, this makes sense, and I'll work on it.

@dtolnay
Copy link
Member

dtolnay commented Mar 13, 2018

As discussed in #48886 -- I believe we should keep this the way it is. Thanks anyway!

@dtolnay dtolnay closed this as completed Mar 13, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-request Category: A feature request, i.e: not implemented / a PR. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants