Cargo features are supposed to be additive, which means the current no_std feature is backwards. This is an issue if you're writing a library, because there is currently no way to pass a negative switch (e.g. if I have a use_std flag, there is no way to say 'enable the no_std flag if it's not enabled.

The current system should be switched, so that there is a use_std feature, which is enabled in the default features.

I'm unsure if even the non-mut AsciiStr <-> [AsciiChar] slice transmutes like this one here are sound, since you generally can't assume that the outer type is compatible with the inner type without using #[repr(transparent)]:

A String is usually preferred to a Box<str>. However, there is one good reason to prefer the Boxed variant to the growable String, which is that String requires more memory. See https://users.rust-lang.org/t/use-case-for-box-str-and-string/8295/4

Similarly, Box<AsciiStr> uses less memory than AsciiString, so it would be helpful if there were ways to convert a AsciiString to a Box<AsciiStr>, just as it is possible to do so for String and Box<str>.

On my machine, Box<AsciiStr> uses 16 bytes compared to 24 bytes for AsciiString.

Thanks for the library. It'd be really awesome if we could add:

• from_byte(u8) -> Ascii <- this one is really necessary as there's no way to implement this without exposed Ascii constructor.
• trim(&AsciiStr) -> &AsciiStr just like String.trim.

If you like the idea I can add these myself and send a pull request.

I noticed in https://github.com/tomprogrammer/rust-ascii/blob/master/Cargo.toml#L12 that we're specifying quickcheck 0.4.1, not a general "^0.4" or "^0.4.1". Would it make sense to specify that instead?

(Sorry, didn't realize that while looking at it earlier!)

See title. I'm not an expert on what subset of const functions are stabilized yet, but I think a lot could already be const fn (think AsciiChar::as_byte).

In AsciiCast impl unconstrained lifetimes appear which were forbidden. (rust-lang/rust#24461)

Feel free to submit a PR.

Since mem::transmute will be const-stable in 1.56.0, it would be nice if there was a way to construct an AsciiStr (and AsciiString) at compile-time. Since the from_str function is in a trait, and thus cannot be const yet, we would probably need to add a new method for this.

These implementations should also exist for AsciiString.

I assume "foo\nbar" producing ["foo"] is a bug,
But the lines_iter() test assert that AsciiStr::from("\n").lines() produces nothing, which is not what I expected, and also differs from str.lines() (which produces a single empty slice).

str.lines() handles "\r\n" and trailing newline, so could the (currently rather complex) implementation be replaced with a simple forwarding implementation?

EDIT on 2018-09-11: fixed typo "foo/nbar"and corrected .split() to .lines().

We could implement std::str::pattern::Pattern to be able to utilize many methods of the standard library.

This issue is waiting for stabilization of rust-lang/rust#27721.

See http://burntsushi.net/rustdoc/quickcheck/trait.Arbitrary.html for a description.

Quickcheck is a randomized testing tool that lets you check general properties. To make your type part of the Quickcheck ecosystem, you need to implement Arbitrary, which involves two methods:

(1) generate a random input
(2) shrink a failing input

This should be relatively easy. See http://burntsushi.net/rustdoc/src/quickcheck/arbitrary.rs.html#391 for how it is done for String and char -- it would probably be straightforward to port that logic to AsciiString and AsciiChar.

This can be behind a feature gate to make sure that if you aren't using quickcheck otherwise, you don't have to pull it in.

(I might do this or get someone else from Facebook to do it -- filing it to keep track :) )

The lines and split methods currently return impl DoubleEndedIterator<Item = &AsciiStr>. It would be nice if they returned a concrete type, similar to std::str::Lines and std::str::Split. A concrete type allows the the iterator to be easily stored in a struct.

From the documentation of std::string::String following traits could/should be implemented for ascii strings:

• FromIterator
• Extend
• Pattern (tracked in #53)
• Default
• Add
• Index (both AsciiString and AsciiStr)
• Write (PR #33)
• More inherent methods on AsciiString

Ideally the APIs should be the same, except the UTF-related bits (like str's utf16_units) and porting programs should be very easy. Currently lots of methods are missing in AsciiStr and AsciiString. (like str.lines(), str.bytes(). str.parse() ...)

Dear all,

Is there any evidence if this crate is faster than Rust std String (for ASCII)?
Did anybody do benchmark or something?

Generally I think there should be a section in README about why should somebody use this crate, for ASCII strings.

Currently the documentation only lists items which are available using std. There should also be online documentation for the core-only feature set.

Hi. I want to use AsciiStr::split(), which is on the document. However, I realized split is not in the latest version (0.9.1) of ascii crate published to crates.io.

Can you please publish next version to crate.io if possible?

Just like &str implements Into<String>.

This would involve copying the string, but would allow writing APIs as:

fn foo<S: IntoAsciiString>(s: S) {
    let s = s.into_ascii_string();
    ....
}

etc, and have those work seamlessly with string and bytestring literals.

I'm working with a C API which requires me to use NUL-terminated, no-interior-NUL, ascii strings. Since the standard library contains CStr and CString types it might be nice if this library contained the ascii equivalents of those as well.

Add characters code from 128 to 255.

It seems that this crate's "Start of Text" member (ASCII '\x02') is mislabeled as SOX, whereas everything else on the web (including the linked-to Wikipedia page) references it as STX.

Since this would be a breaking change, I'm not sure how that would fit within the versioning, but I figured I'd report it anyway since I haven't seen any comments for this on the Issues/PRs for this repo.

ascii_char.rs has this typo:

    /// `'_'`
    Caret = 94,

Obviously, that should be '^'.

Motivation

Preliminary
While str guarantees statically that data of its type is valid UTF-8, the type Ascii guarantees ASCII-conformance. Therefore the types [Ascii] and str and their owned counterparts Vec<Ascii> and String should behave similar.

Topic of this Issue
Ascii provides functions like to_uppercase() and to_lowercase() which can be applied to single ascii-characters. Currently such operations are not implemented on owned or borrowed strings of ascii-characters. As the types Vec<Ascii> and [Ascii] should be opaque manually implementing the iteration isn't recommended because it is a implementation detail of these types.

Example:

error: type `&[Ascii]` does not implement any method in scope named `to_uppercase`
let _ = "abcXYZ".to_ascii().unwrap().to_uppercase();
                                     ^~~~~~~~~~~~~~~~~~~~

Design

The types String and str provide functionality for converting to uppercase and lowercase with their implementations of the traits std::ascii::{AsciiExt, OwnedAsciiExt}. These traits are intended for "[…] ASCII-subset only operations on string slices" and owned strings. Of course Vec<Ascii> and [Ascii] are subsets of ascii, they are equivalent so it's valid to implement them for the ascii only string types.

Implement the traits:

impl AsciiExt<Vec<Ascii>> for [Ascii]
impl AsciiExt for Ascii
impl OwnedAsciiExt for Vec<Ascii>

The implementations use functionality present in Ascii if possible.

Design flaws

• The traits std::ascii::{AsciiExt, OwnedAsciiExt} are marked experimental. This shouldn't be a real issue as I expect this crate to follow the way conversions are done in the standard library.
• All functions declared by the traits std::ascii::{AsciiExt, OwnedAsciiExt} carry the infix ascii which is redundant in the case the traits are implemented on Vec<Ascii>, [Ascii] and Ascii. This redundancy must be tolerated to achieve the goals described above.

Drawbacks

• Duplicate implementations arise because the type Ascii implements the same functionality in the functions to_uppercase() / to_ascii_uppercase() and to_lowercase() and to_ascii_lowercase().

Further considerations after discussion

• Deprecate and remove the functions to_uppercase() and to_lowercase() on Ascii in favour of their equivalents in AsciiExt. That removes the duplication mentioned in the drawbacks.

I'm using this crate in a no_std environment by enabling the alloc feature as described in the readme. However, this feature is not included in the 1.0.0 version as the readme seems to imply, so maybe it would be good to publish a new version that includes the alloc feature and any other recent additions?

Why are versions 0.7.0-0.9.2 deleted/yanked from crates.io? Causing build errors for downstream users of this project. E.g.: tiny-http/tiny-http#162

Hi --

Looks like rust-ascii is available under the MIT and Apache 2.0 licenses. Could you include the respective license files in the repo?

Thanks!

I'm a rust beginner, so maybe I'm just doing it wrong. But I can't seem to find a nice way to convert an array or slice of AsciiChar into a str (via &AsciiStr).

The best I could come up with is this, but it still seems overly verbose:

    let mut s = String::new();
    s.push_str(AsRef::<AsciiStr>::as_ref(&[AsciiChar::A, AsciiChar::B, AsciiChar::C].as_ref()).as_str());

If I'm not missing something, it is required only for tests, so it should be in the [dev-dependencies] section

The quickcheck crate has been updated to 0.8 since the last release of ascii which depends on 0.6.
In Debian, we usually package the latest version of crates except if there is a compelling reason to package earlier versions in addition.
See also Debian Bug #927314.

They allow writing non-ASCII values to an AsciiStr which when read out as an AsciiChar will produce values outside the valid niche.

These impls were added by me in 4fbd050, so 0.9, 0.8 and 0.7 are affected.

Here's an example using these impls to create out-of-bounds array indexing in safe code (when compiled in release mode):

let mut buf = [0u8; 1];
let ascii = buf.as_mut_ascii_str().unwrap();
let byte_view = <&mut[u8] as From<&mut AsciiStr>>::from(ascii);
let arr = [0b11011101u8; 128];
byte_view[0] = 180;
assert_ne!(arr[ascii[0] as u8 as usize], 0b11011101);

I don't see any good way to tell users of the crate to stop using these impls:
Deprecation notices on trait impls are ignored (by both Rust 1.38 and Rust 1.9).
Changing the impls to panic or return an empty slice could break working code (that never writes non-ASCII values) at run-time.

The only fix we could make appears to be to remove the impls, telling users of them to do the unsafe pointer casting explicitly. On one hand this will make any accidental users of it aware of the problem when they update Cargo.lock, but it will also break any use that happened to be OK with a minor release, and any reverse dependencies of these uses.
On the other hand doing nothing and hoping nobody accidentally uses these impls feels irresponsible. What do you think @tomprogrammer?
In any case I don't think we need to fix 0.7 and 0.8, as Rust didn't backport the security fix in 1.29.1 to previous affected versions.

https://tomprogrammer.github.io/rust-ascii/src/ascii/ascii_str.rs.html#396

whoops :)

I’m not really interested in maintaining this crate. @tomprogrammer, how do you feel about moving it to https://github.com/tomprogrammer/rust-ascii/ ?

Hello,

While packaging the latest crate for my distribution, I noticed that all files in the published crate have executable bits. This cause issue with one of our packaging script and seems to be an error. Could you remedy this?

Thank you,

AsciiExt and Error are not in core, but some of their methods might still be useful.
We can add feature-gated inherent impls for those methods, but should we?

• description() for ToAsciiCharError and AsAsciiStrError
• eq_ignore_case() for AsciiChar and AsciiStr
• to_ascii_{upper,lower}case() for AsciiChar
• make_ascii_{upper,lower}case() for AsciiStr