Re: [C2x] Disallow function attributes after function identifier

[Gabriel Ravier <gabravier@gmail.com>]

On 6/11/22 11:03, Alejandro Colomar via Gcc wrote:
 > Hi Jonathan,
 >
 > On 6/11/22 00:47, Jonathan Wakely wrote:
 >>     Well, I'd argue the same reasons to remove it from C++.  Don't 
know how
 >>     useful that feature is for C++, though.  I bet not much, but am 
not an
 >>     expert in the language.
 >>
 >>
 >> It's used in libstdc++ because I couldn't get an attribute to work 
in any other location, because it isn't valid at other positions in a 
constrained function template. So no, we can't remove it from C++.
 >>
 >
 > Hmm, okay, not removable in C++.  I'm curious about the specific line 
of code, if you have it around and could link to it. But C++ is huge, so 
anything is to be expected :)
 >
 >>
 >>
 >>
 >>     But, are we sure we want to add this to C?  You know how difficult
 >>     is to
 >>     revert mistakes in C, as opposed to C++, where additions and
 >>     deprecations are more common.
 >>
 >>
 >> To the core language grammar? Are you sure about that?
 >
 > Well, everything is relative.
 >
 > libstdc++ additions, deprecations (and undeprecations) are much more 
common than in the core C++ language (e.g., the deprecation and later 
undeprecation of <std*.h> headers).
 >
 > But breaking changes in the core C++ language are still more common 
than in C, where (sadly) we still have the useless 'auto' for backwards 
compatibility with dead languages, which would be nice in macros with 
the meaning of __auto_type.  Maybe in the 2050s?  :P
 >
 >
 > So, C++ needs this feature.
 >
 > Then in C, we don't need it (I've never seen code reusing the return 
type to declare more than one function, and I hope to never see that 
apart from theoretical investigation).  `int foo(void), bar(void);` 
seems a useless feature in the language to me, but maybe disallowing it 
through an exception to the rules would complicate the wording more than 
help, so if that's kept in the language, I'm fine with it.
 >
 > So we could, and also could not, bring the C++ attribute for that 
useless feature.
 >
 > In C, I don't think that attribute position can have a useful use 
case that can't be achieved by an attribute at the start of the 
prototype, since the language is much simpler.
 >
 > Do we want to add a completely unnecessary feature, just for symmetry 
with C++, even if it poses a danger of breaking (both human and script) 
readability of function declarations/definitions, especially when hidden 
in macros?

I actually don't get the trouble with this. Your tool already can't 
parse declarations if they don't follow a certain coding style, so you 
can just add this restriction to the coding style that's required.

 > I still have the hope that if the feature is finally kept in C23, 
absolutely no-one will ever use it, but then I question the introduction 
in the first place.

Well in the same way, `int long signed const typedef long x;` is valid 
C, and I do hope that nobody will ever use it, but I don't think we 
should change C's grammar to disallow it.

 >
 > Cheers,
 >
 > Alex
 >

Cheers,

Gabriel