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

[Richard Smith]

I don't think a new option is necessary here; if you set both
AllowShortFunctionsOnASingleLine and AlwaysBreakAfterReturnType, the only
reasonable thing you could mean is for the former to overrule the latter.
There doesn't seem to be any inconsistency in saying that
AllowShortFunctionsOnASingleLine has higher priority than
AlwaysBreakAfterReturnType.

(OK, there's a remote possibility that you might mean that constructors,
destructors, and conversion functions can go on a single line, but
functions with return types can't, which is what clang-format does today,
but I don't think that's a reasonable formatting style.)

On Tue, Dec 30, 2014 at 10:01 PM, Adam McKee <Adam.Matthew.McKee at gmail.com>
wrote:

> It does make sense to me that it's impractical to have clang-format
> support all the formatting styles people like.  I think if I was
> maintaining this program, I'd want a stronger justification for increasing
> the number of configuration parameters than I would for making an existing
> parameter able to better co-operate with another existing parameter.
>
> I haven't looked at the source for clang-format yet, but I don't rule out
> having a go at making a patch.  If I do that I'll surely send it to you, to
> get your feedback.
>
> Anyhow, Happy New Year!
>
>
> On Fri, Dec 26, 2014 at 1:17 PM, Daniel Jasper <djasper at google.com> wrote:
>
>> 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.
>>>
>>
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150104/d8206359/attachment.html>