I have done a bunch of Python programming and when programming in Python I don’t find the lack of braces to be a problem most of the time, except occasionally if cutting and pasting code from web pages (then it is a huge pain).
I think Swift has this right though. In my mind, braces indicate groupings of statements. Making the use of them mandatory, I believe is also the right choice to avoid ambiguity as to whether the else clause goes with the inner if or the outer. I believe this discipline is good in that it avoids errors which are hard to detect. Finally, this enforces a consistency across all teams (despite my voting against required self). Being able to use more expressions and fewer statements may quell some people who hate lots of braces. Shameless plug for my new proposal on the ternary thread :-) Further the statements vs expressions where statements are contained in braces and expressions have parenthesis, i think helps to subtly reinforce the differences between the two forms. This is why in my opinion, making statements into expressions is not a good direction for Swift as has been done in other languages, like Ruby. It complicates the programming model. I feel like there is a discussion coming up with this soon as to whether statements and expressions should remain separate in Swift or the two should be combined. Haskell and other functional programming languages have blurred this line, but is it a good thing? In my experience with the ternary thread this came up quite a bit. - Paul > On Dec 19, 2015, at 8:37 PM, Charles Constant via swift-evolution > <[email protected]> wrote: > > This entire thread is just beating dead horse. Having said that; why not > allow braces for closures, and disallow them elsewhere? It doesn't seem like > a deal-breaker, really. I don't think there's much to debate aside from this: > some people worry that significant whitespace makes code more error-prone, > and others feel the increased legibility makes it less error-prone. > > On Sat, Dec 19, 2015 at 5:58 PM, Kevin Ballard via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > There is not in fact an emphasis on conciseness. This has been repeated many > times by the swift team. Conciseness is not a goal of Swift, but > expressiveness absolutely is. Braces are a well-understood and simple way to > express the notion of a scope/closure. And FWIW removing braces means you > have to come up with a completely different syntax for closures, because > indentation does not suffice there. > > Also, "don't be like C" is not even remotely a goal of Swift. The Swift > syntax is C-like in many respects. "Be like C" isn't a goal either of course, > but when deciding between two alternatives that have no compelling arguments > either way, picking the one that would be more familiar to Obj-C programmers > is usually a good idea. > > -Kevin Ballard > > On Sat, Dec 19, 2015, at 05:39 PM, Alexander Regueiro via swift-evolution > wrote: > > Has anyone considered removing braces from the Swift language? The main > > alternative would be indentation-based scoping like in Python or Ruby. > > There already seems to be a general emphasis on conciseness, lack of > > redundancy, and a modern syntax. e.g. semicolons are not required for > > single-line statements; brackets have been removed from if/for/while > > expressions, compared to C-style syntax. So, why not go the whole way in > > breaking the C-style connection? The present syntax seems to be shunning C, > > but only slightly. > > > > Thoughts? > > _______________________________________________ > > swift-evolution mailing list > > [email protected] <mailto:[email protected]> > > https://lists.swift.org/mailman/listinfo/swift-evolution > > <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <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
