Layout of arrays

[gnzlbg]

Rendered.

Closes #91 .

[RalfJung]

I think this can be ordered better, to be more understandable:

• First the definition of stride.
• Then a section with some consequences of that definition: When size is a multiple of align, then stride == size. This is mandated for the element types of a SIMD vector. In fact this holds true for all current Rust types.
• Then the "open question" section.

Giving the hypothetical example where A has size 3 so early is really confusing.

[hanna-kruppe]

I don't think this chapter should at all try to accomodate hypothetical future language extensions that allow array stride to differ from the size in other contexts. Besides all the reasons that it's unlikely to ever happen (backcompat hazards, massive churn, questionable gains [1]), writing for this hypothetical future complicates the wording of the layout documentation and it seems difficult to adequately describe that future without being misleading about or distracting from the status quo.

It's also far from obvious to me what terminology would be used if it ever comes to that, so however we described it now might turn out to be "wrong" in the future. For example, it seems equally plausible that the current size_of would remain unchanged and so correspond to that's called stride here, and a new term would be introduced for "size without trailing padding".

I am also concerned that if this text distinguishes size_of specifically (as opposed to another concept of "size") from the stride, then unsafe code authors will be in a pickle: how are they to reason about the size of an array? To be compatible with the claimed future extension, they'd need the stride, but there's no way to access that today, they have only size_of.

[1]: the gains are questionable because small types benefit the most from nixing padding, but those same types also benefit from being padded to word alignment so they can be accessed with fewer loads/stores.

[gnzlbg]

they'd need the stride, but there's no way to access that today,

Can't one construct a two element array and measure the pointer offset in bytes? That would be a super annoying thing to do, but is there a case where this is not possible?

[hanna-kruppe]

Hm, you're right, that should work (even in constant expressions) eventually. But I think it'll be so annoying and niche that nobody will bother and so the backwards compatibility problem of introducing stride != size would increase further.

[gnzlbg]

Hm, you're right, that should work (even in constant expressions) eventually. But I think it'll be so annoying and niche that nobody will bother and so the backwards compatibility problem of introducing stride != size would increase further.

Sure, like, if somebody wanted to implement or propose this in a more proper form, I'll expect them to add an std::mem::stride::<[T; N]>() intrinsic or similar.

I think here we want to document what we currently guarantee without forbidding future work on that area (EDIT: at least until these issues are closed), but at the same time documenting how things currently work.

[hanna-kruppe]

I don't have a problem with leaving open the possibility of such future changes in some way, I think the current write-up is acceptable if we really want to refuse closing any doors. However, at the same time, I'm sad to put this extra mental burden on unsafe code authors when any such proposal will most likely either die from multiple contradictory backwards compatibility constraint or have to come up with a whole new and weird taxonomy of layout anyway.

[RalfJung]

Looks good, thanks!

[gnzlbg]

@ubsan read this as well and found it ready. We can always amend this in subsequent PRs.