Remove size != stride distinction for array layout

[gnzlbg]

There was some discussion here about removing the size != stride distinction from the array layout chapter: #162

@rkruppe commented:

Even if Rust eventually adds a notion of stride distinct from size, whoever designs and introduces that feature already needs update all our docs to account for it, and there's far more of that than just UCG.

And I find it hard to argue against that.

[RalfJung]

IMO we should keep the option open or basically make an RFC that says "we will never do this". Because if we close the option here we kind of sneakily make almost the same decision but without consulting anyone.

Cc @petrochenkov @Amanieu

[Lokathor]

If we remove it here we just remove a lot of words that have nothing to do with Rust as it is today, without needing to say either way about the future.

The current page is actually confusing and hard to follow because of all the wording about a potential future we probably will not even see.

[hanna-kruppe]

As I wrote in #162, I don't think removing the currently present language is the forward compatibility hazard that @RalfJung says it is. IIUC the concern is, if we have only one notion of size and document all our guarantees in terms of it, we don't have the leeway to tease them apart later where needed to support stride!=size. But we're not actually doing a good job at being forward compatible in that sense, e.g. as I wrote in #162:

Struct layout would probably be affected too (consider struct Foo(u16, u8); struct Bar(Foo, u8);) but there's no mention of the stride/size distinction in the corresponding chapter.

I don't see anyone trying to fix this, or even worrying loudly about it, so IMO this is a half-hearted attempt which just complicates UCG without actually achieving anything. What's more, I think this is pretty inherent to this thing -- you'd have to basically design the feature and the migration strategy completely to be able to say how it interacts with all the matters we're covering in this document (e.g., do <*T>::offset and <*T>::add multiply the offset by the stride or size?).

I'm also repeating myself pointing out that stride==size is greatly entrenched in other documents (reference, rustdoc examples, and probably unofficial resources), in the collective knowledge of Rust programmers, and in lots of unsafe code in the wild. Belief that stride!=size is possible to introduce into Rust today or in the future requires belief that we can somehow solve these all in a backwards compatible fashion. But if that's true, then we can surely also fix the unsafe code guidelines in the same fashion, right?

By the way, "negative RFCs" saying "we will never do anything like this" have been proposed before and loudly rejected. The more plausible alternative is an RFC blessing a feature or giving a (positive) guarantee [1] that is incompatible with another feature (in a certain concrete incarnation -- it's hard to rule out that someone finds a very different way to achieve the same effect!). Which is pretty much what will happen if UCG without such a distinction goes through the RFC process. Of course, this decision should be made in full awareness of what it means, so a note to that effect would be good.

[JakobDegen]

I thought about this a bit and decided that it's worth having an FCP on the procedural component of this.

The Rust language, as it exists today, does not distinguish between size and stride. This FCP proposes that we close this issue and that T-opsem write its spec and other documents without support for such a distinction.

This FCP does not exclude a future change to the language to support size != stride. However, if any proposal for such a change were made, that proposal would be responsible for exaplaining how the opsem and layouts change to accommodate such a distinction.

@rfcbot close

[rfcbot]

Team member @JakobDegen has proposed to close this. The next step is review by the rest of the tagged team members:

• @CAD97
• @JakobDegen
• @RalfJung
• @digama0
• @saethlin

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.

[rfcbot]

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

[rfcbot]

The final comment period, with a disposition to close, 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.