On 6/11/22 14:08, Gabriel Ravier wrote:
> 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.
True-ish. But when I mean that my tool requires a same coding style, I mean that it just requires that the code hasn't been written by some monkey. Things that are not correctly parsed by my tool are of this kind:
int foo(void)
{
return 7;
}
or
#define empty
int foo empty(void)
{
return 42;
}
Modulo errors in the regexes, any rational indentation is supported
(except for K&R definitions, which are also impossible to parse with a
regex, but ISO C deprecated them a long time ago).
> 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.
Fair point :) Cheers, AlexP.S.: Please consider deprecating 'auto' some day. It would be nice to see C++'s auto in ISO C some day, even if it's 2060. I'm not entirely happy doing `#define auto __auto_type` (of course it's UB, but it's nice) ;)
-- Alejandro Colomar Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/ http://www.alejandro-colomar.es/
OpenPGP_signature
Description: OpenPGP digital signature
