Regression in autoderef on ascii traits

[Manishearth]

The following code compiles on stable but gives an error on beta/nightly:

use std::ascii::AsciiExt; 

fn main() {
        let x = "a".to_string();
        x.eq_ignore_ascii_case("A");
}

playpen

<anon>:5:32: 5:35 error: mismatched types:
 expected `&collections::string::String`,
    found `&'static str`
(expected struct `collections::string::String`,
    found str) [E0308]
<anon>:5         x.eq_ignore_ascii_case("A");

This was caused by the new impl of AsciiExt on String: 700ac0e

cc @SimonSapin @alexcrichton

[Manishearth]

The impl is unstable, but IIRC unstable impls are still accessible?

[Manishearth]

This might be an acceptable kind of regression. It's of the "added new impl" type, which we have already said is okay if the only change necessary to fix it is explicit UFCS. In this case, explicit deref is required, which is a similar annotation burden (however, the fact that we have to do this isn't very clear from the error message).

Might need a crater run if we plan to keep it, cc @brson

[SimonSapin]

I’ll move the into_* methods to a separate trait (like they used to be at some point), this should fix this regression.

[Manishearth]

That should work!

[SimonSapin]

I’ve submitted PR #32076. The discussion for what this API should be like is at #27809.

[alexcrichton]

The libs team discussed this during triage today and the decision was to revert the into_ascii_* methods and go back to the state on 1.7 stable today.

[SimonSapin]

@alexcrichton 1.7 doesn’t have any into_ascii_* methods if I’m reading https://doc.rust-lang.org/1.7.0/std/ascii/trait.AsciiExt.html correctly. So is the decision to remove them?

[alexcrichton]

Ah yeah sorry I don't think I explained enough. The plan of action is detailed a little more clearly in the description of #32314, however.