> On Jan 26, 2017, at 1:25 PM, Jordan Rose via swift-dev <swift-dev@swift.org>
> wrote:
>> On Jan 26, 2017, at 09:35, Andrew Trick via swift-dev <swift-dev@swift.org
>> <mailto:swift-dev@swift.org>> wrote:
>>
>>>
>>> On Jan 26, 2017, at 9:29 AM, Ben Langmuir <blangm...@apple.com
>>> <mailto:blangm...@apple.com>> wrote:
>>>
>>>>
>>>> On Jan 26, 2017, at 9:14 AM, Andrew Trick <atr...@apple.com
>>>> <mailto:atr...@apple.com>> wrote:
>>>>
>>>>
>>>>> On Jan 26, 2017, at 9:11 AM, Ben Langmuir <blangm...@apple.com
>>>>> <mailto:blangm...@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.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
