Mark `core::str::from_utf8*` as `deprecated`

[sorairolake]

The following methods were stabilized in Rust 1.87.0:

• <str>::from_utf8
• <str>::from_utf8_mut
• <str>::from_utf8_unchecked
• <str>::from_utf8_unchecked_mut

The only difference between these methods and core::str::from_utf8* such as core::str::from_utf8 is the namespace (str primitive type or core::str module). I don't think there's any reason to use the traditional core::str::from_utf8* instead of <str>::from_utf8* if the MSRV is 1.87.0.

So I propose adding the deprecated attribute to core::str::from_utf8* as follows:

// `library/core/src/str/converts.rs`
#[deprecated(since = "1.87.0", note = "use `<str>::from_utf8` instead")]
pub const fn from_utf8(v: &[u8]) -> Result<&str, Utf8Error> {
    ...
}

Replacing core::str::from_utf8* with <str>::from_utf8* is as simple as:

// some bytes, in a vector
let sparkle_heart = vec![240, 159, 146, 150];

// We can use the ? (try) operator to check if the bytes are valid
-let sparkle_heart = core::str::from_utf8(&sparkle_heart)?;
+let sparkle_heart = str::from_utf8(&sparkle_heart)?;

assert_eq!("💖", sparkle_heart);

[BurntSushi]

I'm not a fan of these kinds of deprecations because there's nothing inherently wrong with using the older APIs. That is, there are no footguns here. The only benefit is unifying on a consistent API. But the cost is churn. I think this would be better served by a Clippy lint.

[kennytm]

There is the precedent of u32::MAX deprecating std::u32::MAX. Unlike this proposal, the constants are marked #[deprecated(since = "TBD")] rather than a concrete Rust version.

[BurntSushi]

Yes, and my opinion is partially formed by the precedent. Fixing all of those deprecation warnings was busywork with almost no gain from my perspective.

[kennytm]

For u32::MAX getting rid of those std::<typename> import is a huge gain imo.

[ChrisDenton]

1.87 is still relatively recent. If we did do this, I'd prefer to wait awhile longer.

[sorairolake]

I suggested a new lint for clippy based on #655 (comment).

I'm not particular about #[deprecated(since = "1.87.0")]. So #[deprecated(since = "TBD")] is also fine.

[dtolnay]

Is there a way to cause deprecation warnings in this code:

fn f() {
    let _ = std::str::from_utf8(b"...");
}

without causing deprecation warnings in this code?—

use std::str;

struct Thing<'a> {
    b: str::Bytes<'a>,
}

fn f() {
    let _ = str::from_utf8(b"...");
}

If not, I am going to be opposed. Making the user rewrite this to <str>::from_utf8(...) is counterproductive.

[pitaj]

@dtolnay yes, we put quite a lot of work into legacy_numeric_constants clippy lint to avoid that kind of thing (when use std::f64; was used for math constants, for instance)

[sorairolake]

From the comments so far, I think it would be better to do this with the clippy rather than the deprecated attribute.