Move callconv, align, addrspace, and linksection annotations in declaration and field syntax #35220

Migrated from #22263.

There are three main syntax possibilities here:

// status quopubfnfoo()align(4)addrspace(.something)linksection(".foo")callconv(.c)void{...}pubvarx:u32align(128)addrspace(.foo)linksection(".bar")=123;struct{foo:u32,ptr:*align(4)Talign(8),}fn()callconv(.c)void// function type expression// in functions, move annotations after the return type (fields and non-`fn` declarations unchanged)pubfnfoo()voidalign(4)addrspace(.something)linksection(".foo")callconv(.c){...}pubvarx:u32align(128)addrspace(.foo)linksection(".bar")=123;struct{foo:u32,ptr:*align(4)Talign(8),}fn()voidcallconv(.c)// function type expression// move the annotations before the `fn`/`var`/`const` and before field namespubalign(4)addrspace(.something)linksection(".foo")callconv(.c)fnfoo()void{...}pubalign(128)addrspace(.foo)linksection(".bar")varx:u32=123;struct{foo:u32,align(8)ptr:*align(4)T,}callconv(.c)fn()void// function type expression

• The second option seems like a clear improvement on the first option (status quo): right now, annotations arbitrarily "break up" a function type, which is confusing and not consistent with where they are placed on fields and non-fn declarations.
• The last option has a clear separation between the annotations and the declaration/return type, which is good for clarity. It avoids confusion where people think that (e.g.) align(4) u32 is itself a type (which it is not). It also improves clarity when aligned pointer types are involved, as in the ptr struct field example.
• The last option models with syntax whether function parameters are in scope for expressions. Function parameters can be referenced in the function return type expression, but cannot be referenced in align/addrspace/linksection/callconv expressions, and this is made clear by the syntax because the annotations appear before the parameter list in source.
• The last option has the downside that the align annotation on struct/union fields cannot be neatly formatted (the field name becomes unaligned with other field names). The first two options avoid this by placing the annotation after the field name and type, so those can be visually aligned.

Are annotation part of the type though ? I imagine one should not be able to convert easily between C abi compatible function pointers and other types of function pointers with different abi ? Same with alignement.
Linksection may not be part of the type, I have no idea about addrspace.
I believe a clarification on 'what is part of the type' and what is 'where the code will be put in the executable' should be adressed first: then we could separate attributes based on that.

align, addrspace, and linksection---which can go on any declaration---are not part of the type. Instead, they give information a declaration's location in memory and in the binary.

callconv is a property of fn types. Actually, I should edit the proposal to include a function type expression under each possibility, will do that now.

i would prefer having the additional attributes after the type, which keeps the following properties:

• var x, const x and fn x keep greppably trivially (which is a strong property of Zig)
• the important parts come first:
  1. it's a function
  2. named foo
  3. it has these parameters
  4. this return type
  5. and has these additional detailled properties
• it keeps the names nicely aligned for declarations
• it's consistent with struct field properties:

struct{foo:Talign(4),bar:*constfn()voidalign(4),// aligns field by 4}

I think that option 3, with callconv, align, addrspace, linksection coming before the declaration keyword (fn, const, or var) makes the most sense. As mentioned in this comment of the GitHub issue, the four can be viewed as modifiers of the binding, no different from pub, export, inline, and noinline - and if the latter group all come before the declaration keyword, the former should match.

A nice consequence of making the modifiers precede the declaration keyword is that type annotations, I believe, will always followed by a punctuation, thus eliminating the possible confusion of var foo: *align(2) u8 and var foo: *u8 align(2). Additionally, we get a very nice symmetry between declarations and pointers thereto: a pointer to align(16) const bar: T will have type *align(16) const T.

Having the modifiers first does mean that the necleus does not appear at the beginning, but I doubt that in practice we'll find many modifier chains long enough so as to confuse the reader. Explicitly-aligned struct fields also become slightly annoying, as they're not horizontally aligned with the rest of the fields, but I think eliminating the confusion of whether or not align refers to the type or the field is worth the inelegance.

I agree with Fri3dNstuff, I maybe would allow to put them before pub.

// move the annotations before the `fn`/`var`/`const` and before field namesalign(4)addrspace(.something)linksection(".foo")callconv(.c)pubfnfoo()void{...}align(128)addrspace(.foo)linksection(".bar")pubvarx:u32=123;struct{foo:u32,align(8)ptr:*align(4)T,}callconv(.c)fn()void// function type expression

I kind of like the way it is right now. The properties most people care about most when reading a function declaration is its name and its return type. With the current order the name is always all the way on the left and the type is always all the way on the right (or at the beginning/end if args are split into muliple lines), which means that both are very easy to find by just starting to read from either end.

That's not the case with either of the alternatives, which means that a reader of a function would have to spend more time searching for the properties they are most interested in.

(granted, fn is to the left of the name but it's always the same so it's very easy to skip over)

Support option 3
Reason 1: #4630
Reason 2: The current placement of these annotations may lead people to mistakenly think that they are part of the type. To be precise: callconv is part of the function type, whereas other annotations are not, but are properties of the location. Among them, linksection is purely a positional attribute, while align and addrspace affect the pointer type. Because of the current annotations' position, I once mistakenly understood align as part of type rather than an attribute of position.

Regarding the alignment issue, I might let pub together with the location annotations to place on the line before the declaration along with other annotations by zig fmt. Their order is: pub (annotation symbol), linksection (annotation location), align and addrspace (annotation location but affect pointer), callconv (part of type)

publinksection(".foo")align(4)addrspace(.something)callconv(.c)fnfoo()void{...}publinksection(".bar")align(128)addrspace(.foo)varx:u32=123;struct{foo:u32,align(8)ptr:*align(4)T,}callconv(.c)fn()void// function type expression