&str and &[u8] have the same layout

[sanbox-irl]

Currently, str and [u8] are promised to have the same layout, but &str and &[u8] are not promised to have the same layout. The std currently assumes that they are promised to have the same layout (https://doc.rust-lang.org/src/core/str/converts.rs.html#172), so this change would have no impact beyond codifying what is already in practice. This PR defines &str and &[u8] to have the same layout, though what that layout is continues to be unspecified.

There are some further steps here that I didn't take:

1. Every rule about slices should probably also apply to str. I have added str in several places in the reference where it otherwise refered to slices, but likely the definition of a slice should also simply include str. This is a bigger conversation and frankly unimportant if...
2. Some version of Make str into a libcore struct (redux) rust#107939 ever getts stabilized. In that case, all of this doesn't matter and str would be removed from the reference. This seems to me to be obviously the better choice.

In any case, this PR represents a fairly incrementalist approach.

Thanks for the insight of those on the Zulip thread here

[workingjubilee]

@rustbot label: +I-lang-nominated +T-lang

[workingjubilee]

@rustbot label: +I-lang-easy-decision

[rustbot]

Unknown labels: I-lang-easy-decision

[chorman0773]

FTR, the standard library has every right to make assumptions about the implementation of the language beyond what the language does guarantees, because it is intrinsically tied to rustc. Not necesssarily a point against making a decision here, but I don't think it's a strong point in favour of stabilizing the equivalence either.

[sanbox-irl]

FTR, the standard library has every right to make assumptions about the implementation of the language beyond what the language does guarantees, because it is intrinsically tied to rustc. Not necesssarily a point against making a decision here, but I don't think it's a strong point in favour of stabilizing the equivalence either.

Agreed -- I actually am going to reword this to make it clear that I mean this isn't a change for Rustc, only a codification of existing decisions

[kpreid]

This statement should probably be generalized to be about all primitive pointer types (&, &mut, *const, *mut), not only &.

[sanbox-irl]

Unnecessary IMO because of https://doc.rust-lang.org/reference/type-layout.html#r-layout.pointer.intro

[kpreid]

Technically unnecessary, yes, but I bet it’ll be confusing.

[sanbox-irl]

What do you think about adding a link afterwards, such as:

A reference `&str` has the same layout as a reference `&[u8]`.

> [!NOTE]
See [pointer layouts](https://doc.rust-lang.org/reference/type-layout.html#r-layout.pointer.intro) for more information on the layout rules of references in general.

That would point people in the right direction but it wouldn't increase the maintenance burden of the spec or be confusing by its over specification (I would, for example, be confused why the str section is repeating something in the pointer section -- it would make me think that perhaps there's something special about &str's relationship to &mut str and &mut [u8], when that isn't the case at all).

[kpreid]

I think that the right thing in general is to have a single formal term which the Reference uses everywhere for “all primitive pointer types” and can link to an appropriate definition, but there isn’t such a term now, so that doesn’t help this PR. I take your point about avoiding repetition, though, so maybe this is a problem to solve entirely separately. Feel free to mark this conversation resolved.

(I say “primitive pointer types” to distinguish from “smart pointer” types which are not guaranteed to have the same layout.)