> On Jan 26, 2017, at 10:25 AM, Jordan Rose <jordan_r...@apple.com> 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?
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
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
