djasper added a comment. You are right that this behavior is what the code authors, but also many other people, like to have and so it is what is engrained in clang-format. There are likely about a million things that fall into the same category. Now we might find that the current default is actually wrong and we have changed many defaults in the past. I don't believe that's the case here and there are more opinions on this thread.
If people still disagree, there is the question of whether a flag should be introduced, and for every single flag that was introduced, somebody did not agree with what clang-format was doing. We have established the bar that has to be met in order for the cost-benefit-ratio of options to be beneficial. I don't see any reason to make an exception here. The fact that it is a rare corner case makes it less likely to be important enough to carry the weight of an option. Creating a second option class (nested, hidden, ...) does not seem to improve the situation to me. That will just create a subsequent mass of additional flags that people have wanted in the past or will want in the future that don't actually carry their weight (in my opinion - and likely speaking for most other clang-format contributors). Discoverability is only one of the concerns about the costs of flags. So in short, unless you can actually meet the usual requirements for flags, the answer is: no. Repository: rC Clang https://reviews.llvm.org/D42787 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
