Uh oh!
There was an error while loading. Please reload this page.
Add equivalents of C's <ctype.h> functions to AsciiExt. - #39659
Conversation
* `is_ascii_alphabetic` * `is_ascii_uppercase` * `is_ascii_lowercase` * `is_ascii_alphanumeric` * `is_ascii_digit` * `is_ascii_hexdigit` * `is_ascii_punctuation` * `is_ascii_graphic` * `is_ascii_whitespace` * `is_ascii_control` This addresses issue rust-lang#39658.
rust-highfive
commented
Feb 8, 2017
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @sfackler (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
sfackler
commented
Feb 8, 2017
cc @rust-lang/libs I've always been a bit annoyed this is a separate trait at all. Might be worth inlining these while we're at it. |
I assume by that you mean folding the entire AsciiExt trait into the types it extends. I don't disagree, but can that be done compatibly? There's already a compatibility kludge (the |
sfackler
commented
Feb 8, 2017
The idea would be that we deprecate this entire module and just move to inherent methods. |
aturon
commented
Feb 8, 2017
Interesting -- I don't think there's a good rationale for them being extension methods right now. (Maybe there was at some point, pre-DST). Given that all the methods include I'm also 👍 on this PR. |
I don't mind doing the work to turn |
aturon
commented
Feb 12, 2017
alexcrichton
commented
Feb 13, 2017
Looks good to me as well! I believe the intention of the trait was to add the method to I'd be tempted to punt the migration to inherent methods (if at all) to a future PR though and go ahead and land this. Thoughts? |
alexcrichton
commented
Feb 13, 2017
@zackw it also looks like tidy may be failing on travis? |
aturon
commented
Feb 13, 2017
Yeah, that probably makes sense. I do think it'd be a nice change, but it's orthogonal. |
Yeah, that's because the added documentation contains two very long URLs. I have just pushed a change to squeeze those lines in under the limit (by shortening the |
alexcrichton
commented
Feb 13, 2017
Shame on you for writing thorough documentation! :) |
zackw
commented
Feb 13, 2017
Okay, now the problem is that the doc tests for the new unstable feature aren't properly annotated to say that they use the new unstable feature. 😝 And the reason I didn't notice this before is that I don't know how to run stdlib doc tests locally. 🤦♂️ Can one of you please tell me how to do that? |
alexcrichton
commented
Feb 13, 2017
Oh you can just prefix the tests with |
That part I know. What I don't know is how to run the doc tests locally, so that I can verify that I did it right before pushing. |
alexcrichton
commented
Feb 13, 2017
Oh for that you can use |
aturon
commented
Feb 13, 2017
We discussed this is the libs team meeting, and we're all in favor of merging as-is. Feel free to open a separate PR to move to inherent methods as well! r=me once the travis failure is addressed. |
zackw
commented
Feb 13, 2017
@alexcrichton Oh, I see now. |
alexcrichton
commented
Feb 14, 2017
@bors: r+ |
bors
commented
Feb 14, 2017
📌 Commit 162240c has been approved by |
Add equivalents of C's <ctype.h> functions to AsciiExt. * `is_ascii_alphabetic` * `is_ascii_uppercase` * `is_ascii_lowercase` * `is_ascii_alphanumeric` * `is_ascii_digit` * `is_ascii_hexdigit` * `is_ascii_punctuation` * `is_ascii_graphic` * `is_ascii_whitespace` * `is_ascii_control` This addresses issue rust-lang#39658. Lightly tested on x86-64-linux. tidy complains about the URLs in the documentation making lines too long, I don't know what to do about that.
Add equivalents of C's <ctype.h> functions to AsciiExt. * `is_ascii_alphabetic` * `is_ascii_uppercase` * `is_ascii_lowercase` * `is_ascii_alphanumeric` * `is_ascii_digit` * `is_ascii_hexdigit` * `is_ascii_punctuation` * `is_ascii_graphic` * `is_ascii_whitespace` * `is_ascii_control` This addresses issue rust-lang#39658. Lightly tested on x86-64-linux. tidy complains about the URLs in the documentation making lines too long, I don't know what to do about that.
Add equivalents of C's <ctype.h> functions to AsciiExt. * `is_ascii_alphabetic` * `is_ascii_uppercase` * `is_ascii_lowercase` * `is_ascii_alphanumeric` * `is_ascii_digit` * `is_ascii_hexdigit` * `is_ascii_punctuation` * `is_ascii_graphic` * `is_ascii_whitespace` * `is_ascii_control` This addresses issue rust-lang#39658. Lightly tested on x86-64-linux. tidy complains about the URLs in the documentation making lines too long, I don't know what to do about that.
Add equivalents of C's <ctype.h> functions to AsciiExt. * `is_ascii_alphabetic` * `is_ascii_uppercase` * `is_ascii_lowercase` * `is_ascii_alphanumeric` * `is_ascii_digit` * `is_ascii_hexdigit` * `is_ascii_punctuation` * `is_ascii_graphic` * `is_ascii_whitespace` * `is_ascii_control` This addresses issue rust-lang#39658. Lightly tested on x86-64-linux. tidy complains about the URLs in the documentation making lines too long, I don't know what to do about that.
japaric
commented
Feb 15, 2017
Sure! @zackw For For |
Might be simpler to just stick it in the |
japaric
commented
Feb 15, 2017
But |
sfackler
commented
Feb 15, 2017
Oh duh, never mind me. |
| /// Checks if the value is an ASCII graphic character: | ||
| /// U+0021 '@' ... U+007E '~'. | ||
| /// For strings, true if all characters in the string are | ||
| /// ASCII punctuation. |
There was a problem hiding this comment.
s/punctuation/graphic/ here.
SimonSapin
commented
Feb 22, 2017
When doing this, please make sure that |
…r=alexcrichton Copy all `AsciiExt` methods to the primitive types directly in order to deprecate it later **EDIT:** [this PR is ready now](#44042 (comment)). 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
is_ascii_alphabeticis_ascii_uppercaseis_ascii_lowercaseis_ascii_alphanumericis_ascii_digitis_ascii_hexdigitis_ascii_punctuationis_ascii_graphicis_ascii_whitespaceis_ascii_controlThis addresses issue #39658.
Lightly tested on x86-64-linux. tidy complains about the URLs in the documentation making lines too long, I don't know what to do about that.