[swift-evolution] Brace syntax

[Alexander Regueiro]

Interesting discussion. Thank you for the points, Charles and Andrey, in particular. I too consider braces to be “redundant noise” in the same way semicolons are for single-line statements, among other syntactical features. Indeed, it feels like I’m stating myself twice whenever I write them.

There have also been a few votes against removing braces, but these seem to be reactionary. Could any of you perhaps clarify why you want to keep them, or is it just the “change is bad” stance?

Thanks.

> On 20 Dec 2015, at 15:52, Dennis Lysenko <dennis.s.lysenko at gmail.com> wrote:
> 
> 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 <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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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 <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151220/01e317bb/attachment.html>