Make `core::str::from_utf8*` methods available on the `str` type

[robertbastian]

Proposal

Problem statement

These are constructors for str, but they live in the core::str module. This means users always need a use core::str import in order to call them as str::from_utf8, or have to fully qualify them. This leads to two ways of doing things, and is also confusing for beginners who might think that core::str imports the type and is always needed when using str.

Motivating examples or use cases

pub use core::str;

fn foo1() -> &'static str {
    str::from_utf8(b"hi").unwrap()
}

pub use core::str; # not needed, even though we use `str`

fn foo2() -> &'static str {
    "hi"
}

fn foo3() -> &'static str {
    core::str::from_utf8(b"hi").unwrap()
}

Solution sketch

• from_utf8
• from_utf8_mut
• from_utf8_unchecked
• from_utf8_unchecked_mut

become associated functions on the str type. The core::str module reexports them, with a future deprecation warning, as was done for core::i16::MAX and friends.

Alternatives

Everything stays as it is

Links and related work

• https://internals.rust-lang.org/t/why-are-core-from-utf8-not-available-through-the-str-type/21045
• The integer constants RFC, which migrated to associated constants instead of associated methods: https://rust-lang.github.io/rfcs/2700-associated-constants-on-ints.html
• Tracking Issue for str_from_raw_parts rust#119206 adds additional constructors, these should be included if they get stabilised.

Open questions

• There are two str_internals functions, next_code_point and utf8_char_width, not sure whether to include those.

[joshtriplett]

Looks good! Ship it. 🚢

The reaction in today's @rust-lang/libs-api meeting was "why didn't we do this years ago".