> On Jan 26, 2017, at 10:34 AM, Andrew Trick via swift-dev > <swift-dev@swift.org> wrote: > > >> On Jan 26, 2017, at 10:25 AM, Jordan Rose <jordan_r...@apple.com >> <mailto: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.
clang-format bug filed to put this tangent to rest: https://llvm.org/bugs/show_bug.cgi?id=31772 <https://llvm.org/bugs/show_bug.cgi?id=31772> -Andy
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
