On Fri, Sep 16, 2022 at 4:49 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Agreed; I see no need to tolerate any inconsistency.
The check that I used to write the patches doesn't treat unnamed
parameters in a function declaration as an inconsistency, even when
"strict" is used. Another nearby check *could* be used to catch
unnamed parameters [1] if that was deemed useful, though. How do you
feel about unnamed parameters?
Many of the function declarations from reorderbuffer.h will be
affected if we decide that we don't want to allow unnamed parameters
-- it's quite noticeable there. I myself lean towards not allowing
unnamed parameters. (Though perhaps I should reserve judgement until
after I've measured just how prevalent unnamed parameters are.)
> Yeah. I'd be inclined to handle it about like cpluspluscheck:
> provide a script that people can run from time to time, but
> don't insist that it's a commit-blocker.
My thoughts exactly.
[1] https://releases.llvm.org/14.0.0/tools/clang/tools/extra/docs/clang-tidy/checks/readability-named-parameter.html
--
Peter Geoghegan
