Add a potential cause raising `ParseIntError`.
Initially, I wanted to add it directly to the documentation of `str. parse()` method, I finally found that it was more relevant (I hope so?) to directly document the structure in question. I've added a scenario, in which we could all get caught at least once, to make it easier to diagnose the problem when parsing integers.
The error was:
```
[00:05:25] tidy error: /checkout/src/libcore/num/mod.rs:3848: trailing whitespace
[00:05:25] tidy error: /checkout/src/libcore/num/mod.rs:3851: line longer than 100 chars
[00:05:25] tidy error: /checkout/src/libcore/num/mod.rs:3851: trailing whitespace
[00:05:26] some tidy checks failed
```
The line was truncated to 92 characters.
Initially, I wanted to add it directly to the documentation of `str. parse()' method, I finally found that it was more relevant (I hope so?) to directly document the structure in question. I've added a scenario, in which we could all get caught at least once, to make it easier to diagnose the problem when parsing integers.
Add non-panicking variants of pow for integer types
Currently, calling pow may panic in case of overflow, and the function does not have non-panicking counterparts. Thus, it would be beneficial to add those in.
Closes#48291.
Relevant tracking issue: #48320
Make ".e0" not parse as 0.0
This forces floats to have either a digit before the separating point, or after. Thus `".e0"` is invalid like `"."`, when using `parse()`. Fixes#40654. As mentioned in the issue, this is technically a breaking change... but clearly incorrect behaviour at present.
Current document takes 2^4, which is equal to 4^2.
This example is not very helpful for those unfamiliar with math words in English and thus rely on example codes.
Currently, calling pow may panic in case of overflow, and the function
does not have non-panicking counterparts. Thus, it would be beneficial
to add those in.
Primitive docs relevant
This fixes the documentation to show the right types in the examples for many integer methods.
I need to check if the result is correct before we merge.
The current `f32|f64.to_degrees` implementation uses a division to calculate 180/π, which causes a loss of precision. Using a constant is still not perfect (implementing a maximally-precise algorithm would come with a high performance cost), but improves precision with a minimal change.
doc: improve None condition doc for `checked_div` and `checked_rem`
This commit improves the condition mentioned in the docs for which `checked_div` and `checked_rem` return `None`.
For signed division, the commit changes "the operation results in overflow" to "the division results in overflow", otherwise there is room for misinterpretation for `checked_rem`: Without considering overflow, `MIN % -1` would be simply zero, allowing the misinterpretation that "the operation" does not result in overflow in this case. This ambiguity is removed using "when the division results in overflow".
For unsigned division, the condition for `None` should be simply when `rhs == 0`, as no other overflow is possible.
Add "Basic Usage" to int min_value and max_value docs
This adds "Basic Usage:" to the docs of `min_value` and `max_value`, which makes it consistent with docs of other integer methods.
docs: do not call integer overflows as underflows
In the API docs, integer overflow is sometimes called underflow. Underflow is really when the magnitude of a floating-point number is too small so the number underflows to subnormal or zero. With integers it is always overflow, even if the expected result is less than the minimum number that can be represented.
Mark ascii methods on primitive types stable in 1.23.0 not 1.21.0.
The ascii_methods_on_intrinsics feature stabilization
didn't land in time for 1.21.0. Update the annotation
so the documentation is correct about when these
methods became available.
Some checked operations use `rhs` as a parameter name, and some use
`other`. For the sake of consistency, unify everything under the `rhs`
name.
Fixes https://github.com/rust-lang/rust/issues/46308.
The ascii_methods_on_intrinsics feature stabilization
didn't land in time for 1.21.0. Update the annotation
so the documentation is correct about when these
methods became available.
Stabilize some `ascii_ctype` methods
As discussed in #39658, this PR stabilizes those methods for `u8` and `char`. All inherent `ascii_ctype` for `[u8]` and `str` are removed as we prefer the more explicit version `s.chars().all(|c| c.is_ascii_())`.
This PR doesn't modify the `AsciiExt` trait. There, the `ascii_ctype` methods are still unstable. It is planned to remove those in the future (I think). I had to modify some code in `ascii.rs` to properly implement `AsciiExt` for all types.
Fixes#39658.
Copy all `AsciiExt` methods to the primitive types directly in order to deprecate it later
**EDIT:** [this PR is ready now](https://github.com/rust-lang/rust/pull/44042#issuecomment-333883548). I edited this post to reflect the current status of discussion, which is (apart from code review) pretty much settled.
---
This is my current progress in order to prepare stabilization of #39658. As discussed there (and in #39659), the idea is to deprecated `AsciiExt` and copy all methods to the type directly. Apparently there isn't really a reason to have those methods in an extension trait¹.
~~This is **work in progress**: copy&pasting code while slightly modifying the documentation isn't the most exciting thing to do. Therefore I wanted to already open this WIP PR after doing basically 1/4 of the job (copying methods to `&[u8]`, `char` and `&str` is still missing) to get some feedback before I continue. Some questions possibly worth discussing:~~
1. ~~Does everyone agree that deprecating `AsciiExt` is a good idea? Does everyone agree with the goal of this PR?~~ => apparently yes
2. ~~Are my changes OK so far? Did I do something wrong?~~
3. ~~The issue of the unstable-attribute is currently set to 0. I would wait until you say "Ok" to the whole thing, then create a tracking issue and then insert the correct issue id. Is that ok?~~
4. ~~I tweaked `eq_ignore_ascii_case()`: it now takes the argument `other: u8` instead of `other: &u8`. The latter was enforced by the trait. Since we're not bound to a trait anymore, we can drop the reference, ok?~~ => I reverted this, because the interface has to match the `AsciiExt` interface exactly.
¹ ~~Could it be that we can't write `impl [u8] {}`? This might be the reason for `AsciiExt`. If that is the case: is there a good reason we can't write such an impl block? What can we do instead?~~ => we couldn't at the time this PR was opened, but Simon made it possible.
/cc @SimonSapin @zackw
We don't want to stabilize them now already. The goal of this set of
commits is just to add inherent methods to the four types. Stabilizing
all of those methods can be done later.
