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,

Alex


P.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/