So, the main thing that I'd want is deterministic output based on the code structure (thus norespectsExistingLineBreaks), but without the "squishing" that comes with a line limit of 120 (pretty typical for iOS) for simple classes, extensions, etc.

But, I don't know that nested braces alone get exactly my ideal formatting. It's pretty subjective, but single-line functions:

func example(arg: Int) -> Int { return arg }

and single lineif:

if something { print("something!") }

Don't feel "normal" (whereas single-line computedvar andguard/else do... can't explain it!). Maybe the former is different with implicit single-expression returns fromfunc being allowed now though!

But, it's less important than avoiding the excessive squishing. I think overall I prefer theresult of this, but:

1. If the complexity of special-casing so many constructs is too much, a simpler approach is definitely valid, and will get most of the way there.
2. I made them all separate settings, just going off everything existing being a pretty small config option. But, to reduce complexity somewhat (in config, not so much in the implementation), they could just be one "more line breaks!" option to reduce the number of variations in outputs. Depends whether you value consistency or flexibility inswift-format (e.g.black is very inflexible,clang-format is very flexible).

Since there's no "blessed" style at this time, I'm open to some degree of configurability, but I also want to avoid having so much that it becomes difficult to maintain, since the current architecture of the pretty printer is such that some options can interact with each other and that causes a combinatorial explosion of edge cases that we'd need to test thoroughly.

The only real constraints (at this time) are that new features do not affect the behavior of the formatter under the default configuration, so that people using it without a configuration don't have their formatter change suddenly.

It's not exactly what you had in mind, but I think I'd be more inclined to partition curly brace behavior based on whether the braces define the body of a type declaration, the body of a non-type declaration (computed property, function), or the body of a statement (if,while, etc.) and allow customization of those categories. That seems better from the point of view of users defining a configuration, so they don't have to audit each individual structure.

I want to add tuples to this discussion. I would love to see long unnamed and named tuple arguments break into several lines just as functions do. Why? There's a big movementaway from protocols over to structs. Our codebase uses this a lot and many of the tuples are hard to read.

❌ Current result

structPeopleSearchService{varquery:(      _ query:String?, _ orderBy:String?, _ ascending:Bool?, _ limit:Int?,      _ offset:Int?)->[String]}structCarSearchService{varquery:(      _ args:(        query:String?, orderBy:String?, ascending:Bool?,        limit:Int?, offset:Int?))->[String]}

✅ Wanted result

structPeopleSearchService{varquery:(      _ query:String?,      _ orderBy:String?,      _ ascending:Bool?,      _ limit:Int?,      _ offset:Int?)->[String]}structCarSearchService{varquery:(      _ args:(        query:String?,        orderBy:String?,        ascending:Bool?,        limit:Int?,        offset:Int?))->[String]}

{"respectsExistingLineBreaks":false,"lineBreakBeforeControlFlowKeywords":true,"lineBreakBeforeEachArgument":true,"lineLength":80,"maximumBlankLines":1,"respectsExistingLineBreaks":false,"prioritizeKeepingFunctionOutputTogether":false,"lineBreakAroundMultilineExpressionChainComponents":true,"rules": {"BlankLineBetweenMembers":false,"MultiLineTrailingCommas":true,"OneCasePerLine":true,"OneVariableDeclarationPerLine":true,"OnlyOneTrailingClosureArgument":true,"UseSingleLinePropertyGetter":true,  },"tabWidth":4,"version":1}

protocolCompanySearchService{func query(    query:String?,    orderBy:String?,    ascending:Bool?,    limit:Int?,    offset:Int?)->[String]}structMyCompanySearchService:CompanySearchService{func query(    query:String?,    orderBy:String?,    ascending:Bool?,    limit:Int?,    offset:Int?)->[String]{return["a","b","c"]}}structPeopleSearchService{varquery:(      _ query:String?, _ orderBy:String?, _ ascending:Bool?, _ limit:Int?,      _ offset:Int?)->[String]}letmyPeopleSearchService=PeopleSearchService(query:{(query, orderBy, ascending, limit, offset)inreturn["a","b","c"]})structCarSearchService{varquery:(      _ args:(        query:String?, orderBy:String?, ascending:Bool?,        limit:Int?, offset:Int?))->[String]}letmyCarSearchService=CarSearchService(query:{ paramsinlet(query, orderBy, direction, limit, offset)= paramsreturn["a","b","c"]})

@allevato are there any plans on reviving this PR? Would be great to have it!