Repository navigation
<ctype.h> functions for AsciiExt #39658
Description
As discussed at https://internals.rust-lang.org/t/improvements-to-asciiext/4689 I have added is_ascii_* equivalents of most (not quite all) of C's ctype.h's isxxx functions to the AsciiExt trait.
The new functions are
is_ascii_alphabeticis_ascii_uppercaseis_ascii_lowercaseis_ascii_alphanumericis_ascii_digitis_ascii_hexdigitis_ascii_punctuationis_ascii_graphicis_ascii_whitespace(matches the Infra Standard definition of ASCII whitespace, not POSIX)is_ascii_control
They are implemented for char, u8, str, and [u8], and, for backward compatibility with external trait implementations, have default implementations that call unimplemented!().
PR to follow, but I needed to file this bug in order to get an issue number to put in the stability annotations.
Activity
Add equivalents of C's <ctype.h> functions to AsciiExt.
Rollup merge of rust-lang#39659 - zackw:asciiext-ctype, r=alexcrichton
Rollup merge of rust-lang#39659 - zackw:asciiext-ctype, r=alexcrichton
Rollup merge of rust-lang#39659 - zackw:asciiext-ctype, r=alexcrichton
Rollup merge of rust-lang#39659 - zackw:asciiext-ctype, r=alexcrichton
SimonSapin commentedon May 1, 2017
Stabilize?
I just wrote
if let b'A' ... b'Z' = b {, it’s not too bad but might have looked nicer asif b.is_ascii_uppercase() {zackw commentedon May 1, 2017
There was a request over in #39659 to deprecate
AsciiExtand convert all the methods to intrinsics onstr,[u8], etc. but I never got around to it and don't have time in the near future either. I dunno how a plan to do that would affect the stabilization schedule.LukasKalbertodt commentedon Aug 14, 2017
What's the status here? Could I try to "deprecate AsciiExt and convert all the methods to intrinsics on
str,[u8]", create a PR and it might be accepted? Or are there other plans? If there is nothing except "lack of time" blocking this, I might be able to help.zackw commentedon Aug 14, 2017
LukasKalbertodt commentedon Aug 22, 2017
Right now
AsciiExtis implemented for&[u8]andu8. When copying allAsciiExtmethods to the individual types, shall I also copy them for&[u8]andu8? I kinda doubt those implementations are really useful. And it also doesn't make sense not to implement it foru16(e.g. an array of utf16 codepoints), too.What do you think?
35 remaining items
SimonSapin commentedon Mar 17, 2018
Deprecation PR for the
AsciiExttrait: #49109Deprecate the AsciiExt trait in favor of inherent methods
Rollup merge of rust-lang#49109 - SimonSapin:deprecate-asciiext, r=al…
Rollup merge of rust-lang#49109 - SimonSapin:deprecate-asciiext, r=al…
LukasKalbertodt commentedon Mar 23, 2018
Shouldn't this issue also track "removing of unstable
AsciiExtmethods"? Otherwise we might forget to remove those. Or was there already a PR doing that which I missed?SimonSapin commentedon Mar 23, 2018
I don’t know how useful it is to track such features individually. We can occasionally do a pass on the entire standard library looking for items that are both unstable and have been deprecated for a while.
LukasKalbertodt commentedon Mar 23, 2018
@SimonSapin Ah, I missed the fact that the unstable methods were also marked deprecated. That makes sense then!
BartMassey commentedon Jun 11, 2018
I'm disappointed that there is now no officially-supported version of
is_ascii_lowercase()and friends forstr. This was functionality I was using, and it's annoying to go back and write out fancy iterators everywhere or provide my own crate for that functionality. I understand moving this stuff out ofAsciiExt, but could we please have the full functionality back?SimonSapin commentedon Jun 12, 2018
@BartMassey IMO
str::is_ascii_lowercasemight have an unexpected behavior. Onchar, the same method tells whether the character is in the rangeatoz, whether it is an ASCII lower-case letter. The "simple" generalization of that to strings is: is this string made entirely of ASCII lower-case letters?However, what one might be looking for, and not realize that
str::is_ascii_lowercaseis different is: if I were to callto_ascii_lowercase, would I obtain the same string? which really means does this string not contain any upper-case letter?Forcing users to write
s.chars().all(something something)makes it apparent what a call actually does.(Maybe
char::is_ascii_lowercase(respectivelyuppercase) should be named something likeis_ascii_lowercase_alphabeticinstead…)BartMassey commentedon Jun 12, 2018
That is an interesting point. There are certainly a number of fine distinctions that can be drawn here: one might reasonably expect that
str::is_ascii_lowercase()might return true if and only if the target contained only lowercase alphabetic ASCII characters, for example.That said, I still feel like the
AsciiExtcrate already defined a behavior for this function, and that the right thing to do would be to preserve that functionality across the move, at least for now. It feels a bit iffy to me to remove existing functionality without going through the RFC process (as far as I can tell?) in the interest of protecting users from using functions wrong. Do we have evidence that people have routinely misunderstood or misusedis_ascii_lowercase()? Its documentation seemed pretty clear to me.There's an underlying problem here in that anything we do to make ASCII more of a first-class citizen is a step toward encouraging folks to routinely write ASCII-only programs. Nobody wants that.
Having said that, tutorials and examples almost always use and pretty much depend on ASCII: things like Exercism and the Advent Of Code series have caused me an occasional "any other language" kind of feeling because the exercises just assume quality ASCII support. Asking newer users to understand how to write the appropriate iterators to complete these exercises seems to me like it might have its own set of issues.
I don't know. I guess I just need to identify or write a crate that has good support for ASCII-only strings and chars and start using it in situations where that's what I'm working with.
AsciiExtwas never that, and so maybe removing it makes a hole that can be filled with something better. (A quick survey of theasciicrate looks promising, although I'd still have to add the string functions, looks like. It's been downloaded quite a lot, which might indicate a real demand for this kind of thing.)For now,
s.chars().all(|c| c.is_ascii() && !c.is_ascii_uppercase())it is, I guess.SimonSapin commentedon Jun 12, 2018
For what it’s worth the addition of
AsciiExt::to_ascii_lowercasenever went through the RFC process in the first place.Interesting, because this behavior is neither
<str as AsciiExt>::is_ascii_lowercase(that’sself.bytes().all(|b| b.is_ascii_lowercase())) nor what I had in mind for the alternative behavior (.bytes().all(|b| !b.is_ascii_uppercase()), without checking that the string is entirely ASCII).Anyway, it’s always possible to add more methods but a closed issue may not be the best place to propose them.