Add Encoding::label()

[talklittle]

Motivation: Get a standard representation of an encoding that can be used between different encoding libraries, like encoding_rs and rust-encoding.

Helpful for servo/servo#13238

[hsivonen]

This is what Encoding::name() is for. The Servo issue doesn't explain the details. Is there a reason why Encoding::name() does not address the use case?

[hsivonen]

Also, is there a reason why rust-url can't identify the encoding by &'static Encoding while making it an opt-in feature so that apps that want to use rust-encoding don't need to pull in encoding_rs?

[hsivonen]

@SimonSapin, is your plan from a year ago for introducing a trait to abstract over encoding libraries still your current plan for rust-url?

[talklittle]

Thanks, didn't realize that it's a case-insensitive match and that there is always a corresponding label that matches the name exactly. https://encoding.spec.whatwg.org/#names-and-labels

[SimonSapin]

Enough desired breaking changes have accumulated that I kinda want to do url 2.0 now, but there are still some blockers and it’s a bunch of work that isn’t scheduled yet. Removing rust-encoding support would be part of that. As to the trait idea, it’s less about supporting multiple libraries than about avoiding a dependency that’s "visible" in the public APIs (and having users provide callbacks instead). cssparser does this. Servo has already migrated from rust-encoding to encoding_rs. I’m not sure if this is still a good idea to be honest…

[hsivonen]

OK. Personally, I prefer establishing a culture of just upgrading stuff in the ecosystem even if the upgrades are in principle "breaking" changes semver-wise and, therefore, require Cargo.toml churn all around, but I can see the point of wishing to hide the concrete public type behind a trait that gets monomorphised away in order to have less Cargo.toml churn.

I foresee the following in semver-wise breaking changes for encoding_rs that aren't source-wise breaking for the current crates.io users of encoding_rs and wouldn't be for rust-url:

1. Make the mem module assert in certain cases in debug builds and increase the minimum Rust version requirement while at it.
2. Switch from the simd crate to nightly-only std::simd and std::arch once mask vectors with performance-wise simd crate-equivalent reductions land in the standard library's copy of std::simd. The outward breaking change would be the minimum Rust version changing.
3. Use std::simd and std::arch unconditionally once both become available on non-nightly Rust. The outward breaking change would be the minimum Rust version changing.

Other potential sources of semver-breaking changes that wouldn't actually break the crate ecosystem source-wise:

• Changes to the design of the mem module if the current bet for how to outperform existing Gecko code is wrong API-wise.
• Changes to optional features around CJK encoder performance vs. binary size.