Hi, Joseph! I'd like to suggest a change in C2x regarding attributes. Right now, the draft allows function attributes to go right at the beginning of a function prototype, or just before the opening parenthesis: [[attr]] type f(params); type f [[attr]](params); I'd argue against the second one, for the following reasons: C programmers are used to the "f(...)" notation so much that it would be a bit confusing to change that. See for example a linux-man@ discussion: . Not only that, but it's common practise to hide attributes in macros, as in: #if __STDC_VERSION__ > 201710L #define my_inline [[gnu::always_inline]] #else #define my_inline __attribute__((__always_inline__)) #endif Now see a valid C2x function prototype: my_inline type f(params); type f my_inline(params); I hope no-one will ever write that code, even if ISO C ever allows it, but I'd rather see ISO C to forbid that aberration. And, as much as that becomes human unreadable, it also makes it impossible for simple utils to parse C code. I'm writing a PCRE-based tool that finds declarations and definitions within source code repositories. It's already quite good, if we take into account it's simplicity. Since it doesn't involve anything close to a compiler, it can only make a best guess, based on the assumption that the code follows some sane coding style. For example, the PCRE regex for finding a function prototype is '(?s)^[\w[]([\w\s\(,\)[\]*]|::)+[\w\s\)*\]]\s+\**'"$1"'\s*\(([\w\s\(,\)[\]*]|::)+?(\.\.\.)?\)([\w\s\(,\)[\]]|::)*;' See the whole program (sh(1) script): That would be completely broken if anything could go after the function identifier. So, could you please drop that from C2x? Cheers, Alex P.S.: The latest draft that I know of is N2731. I guess there are newer ones. Could you please name the latest one? -- Alejandro Colomar Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/ http://www.alejandro-colomar.es/