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

[Daniel Jasper]

I think Richard is right, though.

AllowShortFunctionsOnASingleLine should simply trump
AlwaysBreakAfterReturnType. Renaming the latter might or might not make
sense, but I don't think introducing an enum for it is necessary.

(Also BreakAfterReturnType=never would be very misleading as clang-format
would break after the return type, but that is beside the point).

On Mon, Jan 5, 2015 at 11:20 PM, Adam McKee <Adam.Matthew.McKee at gmail.com>
wrote:

> 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/20150106/0464f31e/attachment.html>