On Fri, Sep 16, 2022 at 4:49 PM Tom Lane <t...@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
