[cfe-dev] break after definition return type, but only if function can't be a one-liner?

[Daniel Jasper]

As for the option: It has never been the intention of clang-format to
support any style that someone somewhere has come up with. We'd rather
support a limited set of established styles really well. You could probably
make an argument that we have already lost that war, looking at the number
of options that clang-format already has. However, we still have the
general rule that we'd rather introduce options only for stuff that is used
in big (ideally open-source) projects or publicly available style guides.
Now again, I don't think this option will have a terribly high maintenance
effort, but it is also not trivial. At least until we are able to pull out
a better abstraction for "do this if stuff fits/doesn't fit on one line". I
still haven't made up my mind. Are you willing to prepare a patch showing
what this would actually look like?

As for a plugin mechanism: I have not come up with a good way to do this
yet. Especially, I have so far failed to see what the right level of
abstraction would be here. Basically every single of such options requires
manipulating a separate set of things. And I am also unsure whether this
solves anything. Somebody writing such a plugin will still file the same
bugs if we change a different part of clang-format breaking the plugin's
behavior. And then we are in pretty much the same situation except that we
might not have the test cases we need and no good way to reproduce the
behavior.

On Thu, Dec 25, 2014 at 4:19 PM, mobi phil <mobi at mobiphil.com> wrote:

> first, hope that everybody is having a lovely Xmass time.
>
> it is on my todo list to hack the clang-format tool. Wonder if there is
> some plugin mechanism in place (or if not, why not think about), that would
> accommodate situations presentend by the original poster. It is in my
> opinion a healthy middle way. I think once one would discover the power of
> the tool, would find tons of ways and reasons to deviate from the existing
> bit limited range of options.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141226/80e4787c/attachment.html>