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

[Adam McKee]

If you (re-)read my original post, I wasn't actually asking for
"AlwaysBreakAfterReturnType" to remain, yet act differently when
"AllowShortFunctionsOnASingleLine" is indicated.  I suggested renaming it
to "BreakAfterReturnType", with available settings "always", "never", and
"multiline", where "multiline" means break after return type unless
"AllowShortFunctionsOnASingleLine=true", and the function can fit on a
single line.

Anyway I've been formatting with AlwaysBreakAfterReturnType, and I think I
can live with the loss of the simple one-liners in the class declarations.
It's just really nice to be freed from having to dink around with the
formatting manually, and knowing it's all consistent.

On Sun, Jan 4, 2015 at 3:27 AM, Richard Smith <richard at metafoo.co.uk> wrote:

> 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/20150105/7e1cb0db/attachment.html>