Stabilize some ascii_ctype methods
#46077
Conversation
kennytm
added
S-waiting-on-review
|
@LukasKalbertodt The current nightly version is 1.23.0, unless you mean to backport these to the current beta. |
|
@kennytm Oops, nope, I confused things here. So I'll change my latest commit to |
|
Make them 1.23.0 for now. We can backport it to the next beta if it didn't make it. |
LukasKalbertodt
force-pushed
the
stabilize-ascii-ctype
branch
from
55aba1c to
101bcc5
Compare
|
Ok done. Thanks! |
LukasKalbertodt
force-pushed
the
stabilize-ascii-ctype
branch
from
101bcc5 to
b24629d
Compare
This has been discussed in rust-lang#39658. It's a bit ambiguous how those methods work for a sequence of ascii values. We prefer users writing `s.iter().all(|b| b.is_ascii_...())` explicitly. The AsciiExt methods still exist and are implemented for `str` and `[u8]`. We will deprecated or remove those later.
The feature of those methods was renamed to "ascii_ctype_on_intrinsics".
LukasKalbertodt
force-pushed
the
stabilize-ascii-ctype
branch
from
b24629d to
0337017
Compare
|
@rfcbot fcp merge Awesome, thanks @LukasKalbertodt! |
|
Team member @alexcrichton has proposed to merge this. The next step is review by the rest of the tagged teams: No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
rfcbot
added
the
proposed-final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
rfcbot
added
final-comment-period
|
@bors: r+ Thanks again @LukasKalbertodt! |
|
📌 Commit 0337017 has been approved by |
kennytm
added
S-waiting-on-bors
|
@rust-lang/libs Just to confirm — are we going to backport this to 1.23? |
|
Unmarking as beta-nominated. We basically never want to backport stabilizations with current policy. |
Mark-Simulacrum
removed
the
beta-nominated
|
@bors rollup |
|
The versions needs to be changed to 1.24 in this case. |
|
@bors r- |
The changes didn't land in time for 1.23 and stabilizations won't be backported to beta.
|
@kennytm @Mark-Simulacrum changed it to 1.24 |
|
@bors r=alexcrichton |
|
📌 Commit c5aad96 has been approved by |
|
⌛ Testing commit c5aad96 with merge 1563cfc393ae744ab6a14152e86d3c8e773ff2fc... |
|
💔 Test failed - status-travis |
|
This error doesn't look like it has anything to do with my changes... 😕 Right? What shall I do now? |
|
@bors retry — travis-ci/travis-ci#8821 |
…pe, r=alexcrichton Stabilize some `ascii_ctype` methods As discussed in rust-lang#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 rust-lang#39658.
As discussed in #39658, this PR stabilizes those methods for
u8andchar. All inherentascii_ctypefor[u8]andstrare removed as we prefer the more explicit versions.chars().all(|c| c.is_ascii_()).This PR doesn't modify the
AsciiExttrait. There, theascii_ctypemethods are still unstable. It is planned to remove those in the future (I think). I had to modify some code inascii.rsto properly implementAsciiExtfor all types.Fixes #39658.