@alignOf for all the types #32080

permission for opening this proposal given by @mlugg

Preamble

As of Zig 0.16, @alignOf produces a compilation error when given a vacuous type (e.g. noreturn). The language, however, certainly does have a notion of alignment for these types, as one can create a type const S = struct { foo: u16, bar: noreturn };, create an undefined pointer of type *const S, and then try to cast it to *align(1) const S, *align(2) const S, and *align(4) const S (the first two casts succeeding, the third failing).

Proposal

Make @alignOf a total function, returning 1 for vacuous or comptime-only types, and the expected maximum-of-all-fields for (non-packed) structs and unions.

Behaviour Cases

test{constexpectEqual=std.testing.expectEqual;constA=struct{x:u8,y:noreturn,};constB=struct{a:A,b:u16,};constC=union(enum){b:B,c:Aalign(8),};constD=union{};tryexpectEqual(1,@alignOf(noreturn));tryexpectEqual(1,@alignOf(A));tryexpectEqual(2,@alignOf(B));tryexpectEqual(8,@alignOf(C));tryexpectEqual(8,@alignOf([10]C));tryexpectEqual(1,@alignOf(D));}

In my experience/opinion noreturn-like (uninstantiable) types usually require some kind of special casing:

• If they appear as a struct field, the whole struct becomes uninstantiable.
• If they appear as a union state, that state is uninstantiable.

Treating them like void in my experience usually gives me a more-or-less meaningless result, because the caller should be handling uninstantiable types differently than instantiable ones.

I would personally prefer an interface that returns an optional value for the alignment of a type, being null for uninstantiable types. (Same for @sizeOf and @bitSizeOf btw.)
That way callers can easily plug in a default value when appropriate, but are encouraged to think about whether this particular application really makes sense.

A builtin @isNoreturnLike(T: type) (or @isUninstantiable(T: type) in my personal naming scheme) would also be a generally useful helper. (I'm currently using a userland implementation of this, for a userland implementation of the interface with the optional result.)
To my understanding that is exactly the necessary precondition for not triggering a compile error currently, or returning null at the interface I'm suggesting above.

@rohlem I do agree with your view on the effect of vacuous types as struct fields and union variants (indeed, ever since the type resolution changes, (nominal, unadorned) structs which have at least one vacuous type, and (auto-layout) unions whose variants are all vacuous - are themselves vacuous). Further, I agree with the treatment of vacuous types as unit types being erroneous - I definitely do not want to see @sizeOf(noreturn) resulting in 0 (or any other natural number - for that matter)!

Note, however, that this proposal is not at all concerned with @sizeOf (or @bitSizeOf) - this proposal is just about @alignOf's behaviour. While the size in memory of noreturn (and company) is nonsensical to speak about, their alignment definitely is - and as explained above, must already exist in the compiler, due to independent reasons. Pointers to vacuous types are legal, are not vacuous themselves, and have a runtime representation - they ought to have knowledge of their child's natural alignment then!

Making @sizeOf return a ?comptime_int, or adding another builtin are possibilities (in fact, I suggested changing @sizeOf's return type together with changing @alignOf's behaviour) - all that, however, is a different proposal, which isn't in my authority to make.

@Fri3dNstuff Ah, that makes sense, thank you for the clarification!
I missed the important aspect that this matters for pointers; both undefined ones, and when casting/deducing pointer from other pointers / types, sorry about that. My mind jumped from @alignOf directly to composition, container member layout and ordering concerns etc., because that's the niche I've used them in so far.

• Alignment of 1 byte is the safest default, as it makes every byte address a valid value.
• Alternatively we could also consider always requiring explicit or deduced alignment annotations, making plain *T a compile error.

Since I haven't dealt with pointers to vacuous/uninstantiable types as much yet, I don't have a strong opinion about the weight of the ergonomic tradeoffs either way.

EDIT: I'm also not yet sure when it's ever beneficial to increase the alignment of a vacuous type. That is, where the proposed behavior of @alignOf(struct {a: u16, b: noreturn}) != @alignOf(noreturn) is sensible/useful.
I think I see the argument for it being more regular, but then again vacuous types are themselves irregular. (@alignOf(noreturn) must be chosen/prescribed, since it can't be deduced by the existing rules alone.)

The current behavior essentially stems from me just wanting to get something out the door ASAP when I was working on the type resolution PR. Now that I've taken a moment to consider this, this proposal seems like the obviously correct behavior. @alignOf should work on all types, because all types are valid as pointer children, in which case the alignment clearly matters.

I'm personally prepared to accept this. I'll double-check with Andrew next opportunity I have, and if he's okay with it I'll mark this as accepted.

@rohlem wrote in #32080 (comment):

I'm also not yet sure when it's ever beneficial to increase the alignment of a vacuous type. That is, where the proposed behavior of @alignOf(struct {a: u16, b: noreturn}) != @alignOf(noreturn) is sensible/useful. I think I see the argument for it being more regular, but then again vacuous types are themselves irregular. (@alignOf(noreturn) must be chosen/prescribed, since it can't be deduced by the existing rules alone.)

This is mostly for simplicity reasons - yes, the compiler could choose @alignOf(struct { a: u16, b: noreturn }) to be 1 - but that requires more code in the implementation, more lines of specification, more complicated rules in the language reference, and... for what benefit?

Vacuous types are unique, and @alignOf(noreturn) can been chosen to have any value (1 is just the most useful of the bunch) - but this simple rule of "maximum of all fields" means that only noreturn (and anyopaque too! that guy really should have an inspectable alignment! we see *anyopaque values all over) must be prescribed an alignment, instead of all vacuous types. Making structs' and unions' @alignOf computation mechanical like that means @alignOf is completely oblivious to the very notion of instantiability!