mgehre added a comment.
Thanks @njames93, this is a good examples which I did not consider yet. I agree
that only transforming
the second loop would make the code worse.
I would argue that a human seeing a warning on the second loop might also
realize
that the first loop can be transformed in a similar way, and possibly combine
them into
return llvm::all_of(getConds(), [](const Init *Cond) { return Val->Cond(); })
&& llvm::all_of(getVals(), [](const Init *Val) { return Val->isConcrete(); });
(I was wondering whether the check should have an option to suggest
`llvm::all_of` (or `boost::algorithm::all_of`, ...) instead of `std::all_of`,
but
I thought that this could go into another PR.)
I have the feeling that extracting code into algorithms is generally a hard
topic,
and automatic fixits would possible give a false sense of automatism (at least
at the current point).
Your example is a good reminder of that.
Personally, clang-tidy has been a good source of learning C++ best practices.
And I hope that this clang-tidy check would help
me and my coworkers to remember using those algorithms.
Are you saying that this check should not land unless its scope is extended?
What would be the minimal scope making this check
worth-while to land?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D77572/new/
https://reviews.llvm.org/D77572
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
