Stabilise inherent_ascii_escape (FCP in #77174) by clarfonthey · Pull Request #9...

This doesn't really matter -- particularly with the inline annotation -- but it feels like this should take u8 rather than &u8.

I guess we've already FCP'd with this signature and changing the signature might cause some use sites to break at this point, but seems unfortunate.

This is an unfortunate side-effect of all the AsciiExt methods being moved to inherent versions while retaining the references. :(

Sadly, it's the most consistent with the other ASCII methods.

The tracking issue FCP is actually for fn escape_ascii(self) -> ascii::EscapeDefault, and it looks like the original PR introducing these had a similar comment to mine requesting we use self (#73111 (comment))

I think we should update this to be self rather than &self prior to stabilizing it; consistency with other methods isn't really important.

Oh wow, that's 100% my bad. I'll make another PR to merge that change then rebase this on that. Not sure whether you'd wanna do a second FCP or just merge it.

(rebase done, pending tests passing)

I don't think we need a second FCP, I'm happy to r+ this PR directly.

Sounds good to me! Figured I'd be safe just in case you wanted to wait a bit between the change and stabilisation.

FWIW, self vs &self matters quite a bit when the method in question is passed as a function pointer, eg. to an iterator combinator. Having to eta expand Foo::bar to |x| x.bar() is a papercut, particularly if it's inconsistent.