tl;dr If there are no objections I'd like to change clang-format's LLVM
style to always put `template <...>` on its own line.
I would not like this change.
I think it's a general code-layout consistency win and avoids some cases
where trivial code changes result in significant formatting differences
(see the last example).
There are innumerable other such cases. I don't know that this in and of
itself is an important goal. Personally, I favor compactness and brevity of
reading the code slightly over this. I'm sure others will have different
opinions and valuations. I'm not sure there is a significant consensus
behind this particular issue.
I would prefer that two pieces of code with similar logical structure to be
similarly formatted, as much as reasonable, and I think that always
breaking on template declarations is reasonable.
It's all in the trade offs you're willing to make. There are several things
in clang-format today that will attempt a significantly different layout of
code in order to minimize the number of lines required even though it only
works when things happen to fit within 80 columns. I think those are still
worth having because often, things fit within 80 columns! =D
I hate to bring up such a microscopic issue, but I find myself manually
fixing clang-format's behavior with LLVM style when it comes to putting
`template <...>` on its own line, since TBH I feel like a reviewer would
ask me to change it.
I, as a reviewer, would not ask you to change it. I can't recall i single
review where this has come up. I don't think this alone is a good
motivation.
I'll point out that while you give an extreme example in one direction,
there are extreme examples in the other direction as well:
template <int N> template <int M> struct my_trait_a : true_type {};
template <> template <> struct my_trait_a<1, 2> : false_type {};
template <> template <> struct my_trait_a<2, 3> : false_type {};
template <> template <> struct my_trait_a<3, 4> : false_type {};
template <> template <> struct my_trait_a<4, 5> : false_type {};
I don't really relish these constructs consuming 3x the number of lines.
Both of these are extreme cases, and they trade off differently. I think
for the common case neither solution is bad, and the current behavior
consumes slightly fewer lines of code. I think that's a reasonable stance
and would vote to keep it.