Implement `std::ascii::AsciiExt` and `std::ascii::OwnedAsciiExt` for `Ascii` about rust-ascii HOT 5 CLOSED

Makes sense to me. There is no particular reason these impl don’t exist yet, I just didn’t think of adding them.

The traits std::ascii::{AsciiExt, OwnedAsciiExt} are marked experimental.

All stability markers were just copied from std::ascii without any thought and could use being revisited. Also it’s unclear that they mean anything or should be used outside of libstd. See discussion starting at rust-lang/rfcs#507 (comment)

Duplicate implementations arise because the type Ascii implements the same functionality

Just remove Ascii::to_uppercase and Ascii::to_lowercase.

from rust-ascii.

See discussion starting at rust-lang/rfcs#507 (comment)

That is a good source of information, thanks. I consider rethinking the stability of the items in the crate.

Just remove Ascii::to_uppercase and Ascii::to_lowercase.

I didn't remove Ascii:to_uppercase and Ascii:to_lowercase because they are marked stable, but as long as rust has not reached 1.0 the API can change often. But the other stability markers also need recondsideration.

I'm also following the IO reform RFC in which the OsStrBuf, etc. types are also statically enforcing certain conformance. In that manner the motivation of OsStrBuf is similar to Ascii. You also participated there.

from rust-ascii.

I didn't remove Ascii:to_uppercase and Ascii:to_lowercase because they are marked stable

Again, the stability markers only have the meaning we give them. The point of moving things out of libstd is that you don’t have to provide the stability promises. It’s OK to make breaking/backward-incompatible changes as long as the version number is changed appropriately per SemVer. (Of course, as a library matures and gets more relied on, breaking changes should become infrequent and made more thoughtfully…)

from rust-ascii.

I had a very strong reliance on the stability markers. The discussion you linked above brought some new points about the stability markers to me I didn't consider before. You are right that respecting SemVer is usually enough for a library to not break code using it immediately. Thanks for making this clear to me.

from rust-ascii.

It all depends on how many compatibility promises you, as a library maintainer, want to make. "Zero promises", although maybe painful for users, is a valid position. Stability markers and SemVer are just tools to express this. The Rust ecosystem has a relatively strong convention on SemVer, but you don’t have to use it either.

from rust-ascii.