Add equivalents of C's <ctype.h> functions to AsciiExt. #39659

zackw · 2017-02-08T22:46:39Z

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 #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.

* `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 · 2017-02-08T22:46:53Z

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 · 2017-02-08T22:47:45Z

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.

zackw · 2017-02-08T22:49:17Z

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 unimplemented!s) in here...

sfackler · 2017-02-08T22:55:16Z

The idea would be that we deprecate this entire module and just move to inherent methods.

aturon · 2017-02-08T22:56:17Z

@sfackler

I've always been a bit annoyed this is a separate trait at all. Might be worth inlining these while we're at it.

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 ascii in their name, this seems reasonable to me.

I'm also 👍 on this PR.

zackw · 2017-02-09T01:06:57Z

I don't mind doing the work to turn AsciiExt into inherent methods, but I don't understand how libstd, libcore, and libcollections are organized well enough to know where to put the inherent methods. I'm going to need some help with that.

aturon · 2017-02-12T00:23:54Z

@japaric, any chance you'd be willing to help @zackw here, given that it may require some more inherent method magic around primitive types?

alexcrichton · 2017-02-13T16:12:41Z

Looks good to me as well!

I believe the intention of the trait was to add the method to [u8] and u8 as well, as opposed to just char and str.

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 · 2017-02-13T16:13:01Z

@zackw it also looks like tidy may be failing on travis?

aturon · 2017-02-13T16:41:52Z

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?

Yeah, that probably makes sense. I do think it'd be a nice change, but it's orthogonal.

zackw · 2017-02-13T16:48:19Z

@alexcrichton

tidy may be failing on travis

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 [foo]: tag for them).

alexcrichton · 2017-02-13T17:36:34Z

Shame on you for writing thorough documentation!

:)

zackw · 2017-02-13T17:46:29Z

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 · 2017-02-13T20:08:10Z

Oh you can just prefix the tests with #![feature(...)] to allow them to pass. There should be a few other examples of this throughout the standard library as well

zackw · 2017-02-13T20:45:56Z

Oh you can just prefix the tests with #![feature(...)] to allow them to pass

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. rustdoc --test src/libstd/ascii.rs doesn't work, because it tries to process ascii.rs as a standalone crate.

alexcrichton · 2017-02-13T21:39:12Z

Oh for that you can use ./x.py src/libstd --test-args $name

aturon · 2017-02-13T22:46:51Z

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 · 2017-02-13T23:55:53Z

@alexcrichton Oh, I see now. x.py test src/libstd does run the doctests, but only If all of the #[test] tests succeed. And my computer can't do IPv6, which makes the #[test] tests always have some failures, so I thought the doctests were under a separate x.py invocation. Thanks for the hint.

alexcrichton · 2017-02-14T00:43:53Z

@bors: r+

bors · 2017-02-14T00:43:55Z

📌 Commit 162240c has been approved by alexcrichton

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.

Rollup of 8 pull requests - Successful merges: #39659, #39730, #39754, #39772, #39785, #39788, #39790, #39813 - Failed merges:

japaric · 2017-02-15T19:06:51Z

@aturon

@japaric, any chance you'd be willing to help @zackw here, given that it may require some more inherent method magic around primitive types?

Sure!

@zackw For char, u8 and str, I believe the implementations can simply be moved into the inherent impl blocks:

For [u8], we'll have add a new u8_slice lang time to allow an inherent impl [u8] alongside the generic impl<T> [T] block. The magic for that is around here but I'm not sure if the change will be straightforward. I can look into that part.

sfackler · 2017-02-15T19:08:15Z

Might be simpler to just stick it in the impl<T> [T] block with a where T: u8 bound on the methods.

japaric · 2017-02-15T19:26:05Z

with a where T: u8 bound on the methods.

But u8 is a type, not a trait. Or are you suggesting a "double dispatch" approach?

sfackler · 2017-02-15T19:26:53Z

Oh duh, never mind me.

SimonSapin · 2017-02-22T15:07:21Z

src/libstd/ascii.rs

+    /// 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.


s/punctuation/graphic/ here.

SimonSapin · 2017-02-22T15:13:44Z

When doing this, please make sure that [u8] methods show up in rustdoc output.

@SimonSapin

…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

rust-highfive assigned sfackler Feb 8, 2017

sfackler added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label Feb 8, 2017

Squeeze URL lines under 100 chars wide to make tidy happy.

c2566f6

Add feature annotations to the doctests for ascii_ctype.

162240c

frewsxcv mentioned this pull request Feb 14, 2017

Rollup of 10 pull requests #39800

Closed

frewsxcv mentioned this pull request Feb 14, 2017

Rollup of 9 pull requests #39805

Closed

frewsxcv mentioned this pull request Feb 14, 2017

Rollup of 10 pull requests #39816

Closed

frewsxcv mentioned this pull request Feb 14, 2017

Rollup of 8 pull requests #39818

Merged

bors added a commit that referenced this pull request Feb 14, 2017

Auto merge of #39818 - frewsxcv:rollup, r=frewsxcv

e8154a0

Rollup of 8 pull requests - Successful merges: #39659, #39730, #39754, #39772, #39785, #39788, #39790, #39813 - Failed merges:

bors merged commit 162240c into rust-lang:master Feb 15, 2017

petrochenkov mentioned this pull request Feb 19, 2017

Separate to_lowercase() into correct Unicode and simple implementations #26244

Closed

SimonSapin reviewed Feb 22, 2017

View reviewed changes

zackw mentioned this pull request May 1, 2017

<ctype.h> functions for AsciiExt #39658

Closed

LukasKalbertodt mentioned this pull request Aug 22, 2017

Copy all AsciiExt methods to the primitive types directly in order to deprecate it later #44042

Merged

zackw deleted the asciiext-ctype branch November 17, 2017 17:58

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add equivalents of C's <ctype.h> functions to AsciiExt. #39659

Add equivalents of C's <ctype.h> functions to AsciiExt. #39659

zackw commented Feb 8, 2017

rust-highfive commented Feb 8, 2017

sfackler commented Feb 8, 2017

zackw commented Feb 8, 2017 •

edited

Loading

sfackler commented Feb 8, 2017

aturon commented Feb 8, 2017

zackw commented Feb 9, 2017 •

edited

Loading

aturon commented Feb 12, 2017

alexcrichton commented Feb 13, 2017

alexcrichton commented Feb 13, 2017

aturon commented Feb 13, 2017

zackw commented Feb 13, 2017 •

edited

Loading

alexcrichton commented Feb 13, 2017

zackw commented Feb 13, 2017

alexcrichton commented Feb 13, 2017

zackw commented Feb 13, 2017 •

edited

Loading

alexcrichton commented Feb 13, 2017

aturon commented Feb 13, 2017

zackw commented Feb 13, 2017

alexcrichton commented Feb 14, 2017

bors commented Feb 14, 2017

japaric commented Feb 15, 2017

sfackler commented Feb 15, 2017 •

edited

Loading

japaric commented Feb 15, 2017

sfackler commented Feb 15, 2017

SimonSapin Feb 22, 2017

SimonSapin commented Feb 22, 2017

Add equivalents of C's <ctype.h> functions to AsciiExt. #39659

Add equivalents of C's <ctype.h> functions to AsciiExt. #39659

Conversation

zackw commented Feb 8, 2017

rust-highfive commented Feb 8, 2017

sfackler commented Feb 8, 2017

zackw commented Feb 8, 2017 • edited Loading

sfackler commented Feb 8, 2017

aturon commented Feb 8, 2017

zackw commented Feb 9, 2017 • edited Loading

aturon commented Feb 12, 2017

alexcrichton commented Feb 13, 2017

alexcrichton commented Feb 13, 2017

aturon commented Feb 13, 2017

zackw commented Feb 13, 2017 • edited Loading

alexcrichton commented Feb 13, 2017

zackw commented Feb 13, 2017

alexcrichton commented Feb 13, 2017

zackw commented Feb 13, 2017 • edited Loading

alexcrichton commented Feb 13, 2017

aturon commented Feb 13, 2017

zackw commented Feb 13, 2017

alexcrichton commented Feb 14, 2017

bors commented Feb 14, 2017

japaric commented Feb 15, 2017

sfackler commented Feb 15, 2017 • edited Loading

japaric commented Feb 15, 2017

sfackler commented Feb 15, 2017

SimonSapin Feb 22, 2017

Choose a reason for hiding this comment

SimonSapin commented Feb 22, 2017

zackw commented Feb 8, 2017 •

edited

Loading

zackw commented Feb 9, 2017 •

edited

Loading

zackw commented Feb 13, 2017 •

edited

Loading

zackw commented Feb 13, 2017 •

edited

Loading

sfackler commented Feb 15, 2017 •

edited

Loading