Contrived example Charles. Apple's tutorials consistently put braces on the line of the statement declaration. https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/ControlFlow.html#//apple_ref/doc/uid/TP40014097-CH9-ID120
On Sun, Dec 20, 2015 at 7:16 AM Charles Constant via swift-evolution < [email protected]> wrote: > Andrey's post encourages me to veer into the merits of significant > whitespace vs braces. This is probably unwise of me, since we're not all > going to agree any time soon, but I can't resist pointing out an example: > > //////////////////////////////////////////////////////////////////////// > > var foo: Int > { > get > { > return _foo > } > set > { > _foo = newValue > } > } > > //////////////////////////////////////////////////////////////////////// > > var foo: Int: > get: > return _foo > set: > _foo = newValue > > //////////////////////////////////////////////////////////////////////// > > It's obvious no programmer is going to be consistent about braces in the > first example - it's absurdly verbose. So with braces in Swift, pretty much > everything you write carries the overhead of "what inconsistent way will i > format the braces for this code?" For me, I'd rather throw out the (largely > redundant) noise, and stick with just the content. > > > > > > > On Sun, Dec 20, 2015 at 3:59 AM, Andrey Tarantsov via swift-evolution < > [email protected]> wrote: > >> I don't know many people who have experienced a large variety (8+?) of >> programming languages and prefer Python's forced indentation >> >> >> Count me as one. I'd prefer Swift to have Python-style indentation, just >> on the grounds of braces being stupid (why would you want to enter the same >> scope information *twice*)? >> >> So +1 from me, although I don't suffer from the braces at all. >> >> I do want to point out that the amount of code that fits on a screen *is* >> fairly >> important, and you should keep your methods short, so one less brace per >> method means a couple more methods per screen. >> >> This would also free up braces to mean “closure” in 100% of cases, which >> is good for consistency. >> >> But it would introduce it's share of problems for sure, so I don't feel >> strongly about this proposal. >> >> I also admit that braces are generally preferred, for some mysterious >> reason that I hope a believer can articulate here. Take Sass, for example; >> it has both an indentation-based syntax and a braces-based syntax, and the >> latter one seems way more popular. >> >> A. >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
