[swift-dev] Using git-clang-format in the Swift compiler code base.

[Andrew Trick]

> On Jan 26, 2017, at 10:25 AM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
>> 
>> On Jan 26, 2017, at 09:35, Andrew Trick via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>> 
>>> 
>>> On Jan 26, 2017, at 9:29 AM, Ben Langmuir <blangmuir at apple.com <mailto:blangmuir at apple.com>> wrote:
>>> 
>>>> 
>>>> On Jan 26, 2017, at 9:14 AM, Andrew Trick <atrick at apple.com <mailto:atrick at apple.com>> wrote:
>>>> 
>>>> 
>>>>> On Jan 26, 2017, at 9:11 AM, Ben Langmuir <blangmuir at apple.com <mailto:blangmuir at apple.com>> wrote:
>>>>>> 
>>>>>> ** Option 1: Add a simple configuration option to swift/.clang-format:
>>>>>> 
>>>>>> 1a. BreakBeforeBinaryOperators: All
>>>>>> 
>>>>>> 1b. BreakBeforeBinaryOperators: NonAssignment
>>>>> 
>>>>>> 
>>>>>> I have absolutely no preference between 1a and 1b. It's purely style.
>>>>>> 
>>>>>> 1a:
>>>>>> SomeLongTypeName someLongVariableName =
>>>>>> someLongExpression();
>>>>>> 
>>>>>> 1b:
>>>>>> SomeLongTypeName someLongVariableName
>>>>>> = someLongExpression();
>>>>> 
>>>>> 1b sounds good to me.
>>>> 
>>>> I contradicted myself above. If you like the style shown in (1b), the configuration option is actually BreakBeforeBinaryOperators: All.
>>> 
>>> Glad you mentioned it, because I prefer  “NonAssignment”, but didn’t check your example code against the above description :-)
>> 
>> Alright, I’l reformat my PR with that config, unless anyone else wants to weigh in.
>> 
>> Incidentally, I despise what clang-format does with asserts now:
>>   assert(condition
>>              && “text”)
>> 
>> It’s a consequence of us not using a legit assert package, so I don’t know if I want to push to get clang-format changed.
> 
> What do you want it to do with this style of assert?

assert((precondition1 || predcondition2) &&
           “informative message”)

The boolean operator is filling in for a comma. That’s how it’s meant to be parsed by the reader. It’s presence in the code is purely distracting. From the tool’s point of view, it’s tautological so shouldn’t be given significance as a boolean operator.

-Andy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170126/a718c1f4/attachment.html>