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

[Adam McKee]

Oops, I did a poor job reading what Richard wrote.  After considering it, I
agree it's not appropriate to rename AlwaysBreakAfterDefinitionReturnType
_and_ make an enum for it.  If anything, maybe I would just remove the
"Always" prefix from the name (while keeping it as a toggle option), but
even that may not be necessary.  "AllowShortFunctionsOnASingleLine" seems
to inherently be a higher-priority directive.  There, it occurs to me to
remove the "Allow" prefix.  Saying X is "allowed" seems to be a bit
different from saying "do X whenever you can".  Probably I overthink the
names a bit, though.

On Mon, Jan 5, 2015 at 5:04 PM, Daniel Jasper <djasper at google.com> wrote:

> 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/660fcb84/attachment.html>