Hm. I know this is my wording suggestion, but reading it back in context: We start this paragraph by describing a special case for reference types that doesn't follow the general rule in p1 (and can't because there are no objects of reference type). Following that up with this might be taken as suggesting that this case is also overriding the general rule. Maybe we could move this rule into p1 so it doesn't seem to parallel the reference case?

More drastic suggestion: I wonder if perhaps this wording belongs in [intro.object] instead. Perhaps in paragraph 8 where we talk about objects occupying storage? We could split the second half of p8 into two:

8. [...] Otherwise, the circumstances under which the object has zero size are implementation-defined.

8+. Unless it is a bit-field (11.4.10), an object with nonzero size shall occupy one or more bytes of storage, including every byte that is occupied in full or in part by any of its subobjects. An object of trivially copyable or standard-layout type (6.8) shall occupy contiguous bytes of storage. An object of array type shall not occupy any byte that is not occupied by any of its subobjects.[Footnote: This implies that sizeof(T[n]) == n * sizeof(T).]

Implemented.

I like the wording. Do we all agree that this is editorial?

I think it's editorial; this is what the standard always said. If you're uncomfortable, let's punt this to "editorial with CWG oversight".

@zygoloid, your input solicited.

What do we think the rule for classes is? Is it:

• an object of class type occupies its tail padding, therefore an object of array type does too
• an object of class type doesn't occupy its tail padding but as a special case we increase the value produced by sizeof as described above

The first option seems to disallow tail padding reuse (by the "occupy disjoint bytes of storage" rule). The second option seems to mean that sizeof(T[n]) != n * sizeof(T).

I think the conclusion is probably that sizeof(T) can be larger than the number of bytes occupied by T, and this happens precisely when T has tail padding. :(

I think that the current wording doesn't allow an array element subobject to be potentially-overlapping (but it seems that the array itself is unintendedly allowed, which is meaningless)(CWG2527), and thus it exactly occupies all sizeof(T) bytes according to [expr.sizeof]/1.

IMO nothing is unclear in this PR, but I'm a bit confused that "number of bytes occupied by a non-potentially-overlapping object" is mentioned in [expr.sizeof] only, not in [intro.object].

@jensmaurer Thoughts?

I think we need a consistent model here, and fixing this is likely CWG material.