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

[John McCall]

> On Jan 26, 2017, at 1:25 PM, Jordan Rose via swift-dev <swift-dev at swift.org> 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?

The idiomatic understanding is that the last && is "really" a comma.

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