Treat str as containing [u8] for auto trait purposes

[compiler-errors]

Wanted to gauge @rust-lang/lang and @rust-lang/types teams' thoughts on treating str as "containing" a [u8] slice for auto-trait purposes.

@dtolnay brought this up in #13231 (comment) as a blocker for future str type librarification, and I think it's both a valid concern and very easy to fix. I'm interested in actually doing that str type librarification (#107939), but this probably should be considered in the mean time regardless of that PR.

r? types for the impl, though this definitely needs an FCP.

[rustbot]

Some changes occurred to the core trait solver

cc @rust-lang/initiative-trait-system-refactor

[scottmcm]

Since we've already said that for validity purposes a str doesn't require anything that a [u8] doesn't, this makes good sense to me personally.

Is this observable to stable code in any way? If it was, I guess it'd have to be something about Send/Sync? Do str and [u8] have any differences between those?

[compiler-errors]

My understanding is that we can't observe this through any of the auto traits that the standard library currently exposes.

[scottmcm]

We had a chat about this today in the lang team meeting, and nobody had any concerns under the assumption that it's not visible on stable because Send and Sync don't change. Un-nominating it for lang, and leaving it for T-types.

[compiler-errors]

Ok, well I guess it's worth kicking off an FCP for T-types then.

This PR changes the auto-trait behavior of str. Namely, although str is a primitive, we treat it like it has [u8] as a constituent, equivalent to if it were defined like struct str([u8]); in libcore. This has very low overhead in the implementation of the current trait solvers, and should help us move forward with librarification of str later.

@rfcbot fcp merge

[rfcbot]

Team member @compiler-errors has proposed to merge this. The next step is review by the rest of the tagged team members:

• @compiler-errors
• @jackh726
• @lcnr
• @nikomatsakis
• @oli-obk
• @spastorino

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[jackh726]

So, implementation-wise, I think this fine. But, I guess I'm not personally sure whether str should behave like [u8] or not. (Seems like yes?)

If that answer is yes, then LGTM.

[dtolnay]

To the extent that "whether str should behave like [u8]" is a library API question, I am confident that the library API team's perspective is yes. In the standard library str is conceptually struct str([u8]);. This is reinforced by #71033 where the lang team relinquished the language-level specialness of str (except the connection to string literal syntax obviously, and some name resolution voodoo where there's no type-namespace conflict between str and the core::str module).

To be precise about what "should behave like" means, the pertinent decision for the types team is this:

auto trait AutoTrait {}

impl<T> !AutoTrait for [T] {}

whether str should or should not implement AutoTrait.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[lcnr]

r=me after FCP is finished

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[compiler-errors]

@bors r=lcnr

[bors]

📌 Commit e9a8ff7 has been approved by lcnr

It is now in the queue for this repository.

[compiler-errors]

needed rebase after some EvalCtxt changes in new solver.

@bors r=lcnr

[bors]

📌 Commit 53fb433 has been approved by lcnr

It is now in the queue for this repository.