# Brace syntax **URL:** \ **Category:** Discussion\ **Created:** [December 20, 2015, 1:39am UTC](https://forums.swift.org/t/brace-syntax/678 "2015-12-20T01:39:06Z")\ **Posts on this page:** 16\ **Page:** 2
**Author:** ![MichaelBuckley](https://avatars.discourse-cdn.com/v4/letter/m/7ab992/32.png) [@MichaelBuckley](https://forums.swift.org/u/MichaelBuckley)\ **Post date:** [December 20, 2015, 6:59pm UTC](https://forums.swift.org/t/brace-syntax/678/21 "2015-12-20T18:59:09Z")
Having written a lot of Python code over the last seven years, I definitely prefer braces to significant whitespace, not because I enjoy looking at them or I want to indent my code incorrectly, but because they help my indent my code correctly and keep it correctly indented. The problems I'll describe below are all problems I have had in the real world when working with Python code. Python suffers from the famous tab-spaces problem with significant indentation, which Guido listed is one of this "Python Regrets" in 2002. In short, Python considers tab characters to be worth 8 space characters, but very few if any people have their editor set to tab = 8 spaces. It actually doesn't matter what value you assign to tab. Sone people will have tab = 2 spaces, others 4, and I've even worked with programmers who have it set to 5. The only defense against this is for everyone on a project to stick with either tabs or spaces, and this is why most Python programmers use spaces. But all it takes is one misconfigured text editor to introduce tabs into the project. They likely won't be caught by code review, and they may not immediately cause an error. But later on, they'll end up causing frustrating, difficult-to-diagnose errors. You also need to be paranoid about integrating code from other projects, because they might use tabs. You could try to prevent this is Swift by banning the use of either tabs or spaces in indentation. But this would put you in the middle of a holy war that has been going on for decades, and would be a huge distraction. Not only would you anger those who like either tabs or spaces, but you would anger those who use tabs for semantic indentation, spaces for alignment. The other classic problem, though not as common as it once was, is that HTML doesn't preserve multiple spaces in a row by default. Not a problem when you put the code in preformatted blocks, but there are HTML contexts that will still mangle your code unexpectedly. For example, some Web mail systems out there will display plan-text emails using HTML. My personal pet peeve with significant whitespace is that it makes refactoring code more tedious. Let's say I want to move an if statement out of a loop. I select the statement, cut it, move my text cursor out of the loop to where I want to insert it, make sure I'm indented at the level I want to be, and paste. The first line gets pasted with the proper indentation. All the subsequent lines get pasted with their original indentation, which I now have to fix. Which brings me to the reason why I like braces: They allow text editors to handle the indentation for me. I don't have to worry about it. In the above example, I can just paste the code, and all the lines are indented properly. If I get sent some code in an HTML context that mangles indentation, or code that contains tabs, I can paste it into my text editor, and the editor will indent it properly and remove all the tabs. Critics of tabs tend to focus on the fact that they don't express anything not already expressed by indentation. But as I've explained here, that's not quite true. They provide enough context to text editors to automatically format your code for you. Without them, text editors cannot perform certain formatting operations. Additionally, I have heard tell that one of the original inspirations for Python's significant whitespace code were C bugs caused by programmers who omitted braces and relied on indentation for if statements. In other words, code like the goto fail bug. Swift already takes care of this by making the curly braces mandatory in if statements, so Swift code will not fall victim to the class of bugs that inspired significant whitespace. Python on the other hand, is vulnerable to this kind of bug due to unintentional outdenting. Maybe a programmer, when moving a block, missed intending the last line of the block. Perhaps an errant finger hit the delete key, outdenting the last line of an if statement. Python will now execute this line unconditionally. The equivalent error in braces-based languages, accidentally deleting the closing brace, will just cause the code to not compile. > **···** > > On Sun, Dec 20, 2015 at 8:12 AM, Alexander Regueiro via swift-evolution \< swift-evolution@swift.org\> wrote: > > > 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? ---
**Author:** ![Charles\_Constant](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/charles_constant/32/13103_2.png) [@Charles\_Constant](https://forums.swift.org/u/Charles_Constant)\ **Post date:** [December 20, 2015, 7:02pm UTC](https://forums.swift.org/t/brace-syntax/678/22 "2015-12-20T19:02:17Z")
Yes, I went out of my way to point out that it \*is\* contrived, because even a programmer who uses a newline for the opening brace \*elsewhere\* in the same project, isn't going to take up 11 lines to define one variable. > **···** > > On Sun, Dec 20, 2015 at 7:52 AM, Dennis Lysenko \ wrote: > > > Contrived example Charles. Apple's tutorials consistently put braces on > > the line of the statement declaration. > > [The Swift Programming Language: Redirect](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@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@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@swift.org > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Tino](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tino/32/1073_2.png) [@Tino](https://forums.swift.org/u/Tino)\ **Post date:** [December 20, 2015, 12:22pm UTC](https://forums.swift.org/t/brace-syntax/678/23 "2015-12-20T12:22:36Z")
> var foo: Int > { >     get >     { >         return \_foo >     } >     set >     { >         \_foo = newValue >     } > } I assume you know that braces don't require an extra line for themselves? ;-) ---
**Author:** ![dennislysenko](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dennislysenko/32/41738_2.png) [@dennislysenko](https://forums.swift.org/u/dennislysenko)\ **Post date:** [December 20, 2015, 3:52pm UTC](https://forums.swift.org/t/brace-syntax/678/24 "2015-12-20T15:52:58Z")
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@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@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@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Valentin\_Radu1](https://avatars.discourse-cdn.com/v4/letter/v/ccd318/32.png) [@Valentin\_Radu1](https://forums.swift.org/u/Valentin_Radu1)\ **Post date:** [December 20, 2015, 2:01pm UTC](https://forums.swift.org/t/brace-syntax/678/25 "2015-12-20T14:01:30Z")
I admit this is 100% a personal preference and that dropping the braces would not significantly affect me, but I got used to them and instinctually search code blocks using them. I prefer reading like that, even if that means writing more code. If you think about it, writing code is maybe 20% of the time you spend on an app. -1 > **···** > > > On Sun 20 Dec, 15, at 14:25, Charles Constant via swift-evolution \ wrote: > > > > Yes, that is the point. If you use braces in Swift, you will naturally gravitate to all sorts of personalized strategies. Now this is possible with significant whitespace (e.g.: Python uses the semicolon to put multiple statements on the same line) but not nearly as common. > > > > On Sun, Dec 20, 2015 at 4:22 AM, Tino Heth \<2th@gmx.de \\> wrote: > > > > > var foo: Int > > > { > > >     get > > >     { > > >         return \_foo > > >     } > > >     set > > >     { > > >         \_foo = newValue > > >     } > > > } > > > > I assume you know that braces don't require an extra line for themselves? ;-) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![alexreg](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/alexreg/32/12360_2.png) [@alexreg](https://forums.swift.org/u/alexreg)\ **Post date:** [December 20, 2015, 4:12pm UTC](https://forums.swift.org/t/brace-syntax/678/26 "2015-12-20T16:12:43Z")
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 \ wrote: > > > > Contrived example Charles. Apple's tutorials consistently put braces on the line of the statement declaration. [The Swift Programming Language: Redirect](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 \\> 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 \\> 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@swift.org \ > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org \ > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![alexreg](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/alexreg/32/12360_2.png) [@alexreg](https://forums.swift.org/u/alexreg)\ **Post date:** [December 20, 2015, 7:46pm UTC](https://forums.swift.org/t/brace-syntax/678/27 "2015-12-20T19:46:19Z")
Thanks for sharing your thoughts. I hear what you’re saying, but not sure any of these points are substantial enough to outweigh the benefits. > Having written a lot of Python code over the last seven years, I definitely prefer braces to significant whitespace, not because I enjoy looking at them or I want to indent my code incorrectly, but because they help my indent my code correctly and keep it correctly indented. The problems I'll describe below are all problems I have had in the real world when working with Python code. Fair enough, though I should also say I’ve used the following languages significantly and still prefer tabs (having found braces only to be an annoyance, primarily because of redundancy and/or inconsistent application, & other reasons). C – braces C# – braces F# – tabs Python – tabs Haskell – tabs Javascript – braces > Python suffers from the famous tab-spaces problem with significant indentation, which Guido listed is one of this "Python Regrets" in 2002. In short, Python considers tab characters to be worth 8 space characters, but very few if any people have their editor set to tab = 8 spaces. It actually doesn't matter what value you assign to tab. Sone people will have tab = 2 spaces, others 4, and I've even worked with programmers who have it set to 5. The only defense against this is for everyone on a project to stick with either tabs or spaces, and this is why most Python programmers use spaces. But all it takes is one misconfigured text editor to introduce tabs into the project. They likely won't be caught by code review, and they may not immediately cause an error. But later on, they'll end up causing frustrating, difficult-to-diagnose errors. You also need to be paranoid about integrating code from other projects, because they might use tabs. I think the best and simplest solution for this is just to force tabs to be used for semantic indentation, and disallow spaces. I believe F# does this (and also allows optional spaces which are ignored) – though that could have changed since I last used it. > You could try to prevent this is Swift by banning the use of either tabs or spaces in indentation. But this would put you in the middle of a holy war that has been going on for decades, and would be a huge distraction. Not only would you anger those who like either tabs or spaces, but you would anger those who use tabs for semantic indentation, spaces for alignment. Is this really as big a problem as you make it out? Personally, as a programmer, I \*like\* being constrained in these ways. If there’s only one way to do something correctly, it saves me a potential headache. Also, I thought tabs had won the war(!) > The other classic problem, though not as common as it once was, is that HTML doesn't preserve multiple spaces in a row by default. Not a problem when you put the code in preformatted blocks, but there are HTML contexts that will still mangle your code unexpectedly. For example, some Web mail systems out there will display plan-text emails using HTML. > > My personal pet peeve with significant whitespace is that it makes refactoring code more tedious. Let's say I want to move an if statement out of a loop. I select the statement, cut it, move my text cursor out of the loop to where I want to insert it, make sure I'm indented at the level I want to be, and paste. The first line gets pasted with the proper indentation. All the subsequent lines get pasted with their original indentation, which I now have to fix. This is not a significant issue for me. We can’t help other software being stupid (or other languages having small deficiencies). I don’t think it crops up enough anyway. > Which brings me to the reason why I like braces: They allow text editors to handle the indentation for me. I don't have to worry about it. In the above example, I can just paste the code, and all the lines are indented properly. If I get sent some code in an HTML context that mangles indentation, or code that contains tabs, I can paste it into my text editor, and the editor will indent it properly and remove all the tabs. It’s all about what you consider primary. Sure, you don’t have to worry about indentation then (or very little) if you use braces and have an editor that auto-formats. But equally you don’t have to worry about any braces (or lack of braces in single-line cases especially), if you use semantic indentation. > Critics of tabs tend to focus on the fact that they don't express anything not already expressed by indentation. But as I've explained here, that's not quite true. They provide enough context to text editors to automatically format your code for you. Without them, text editors cannot perform certain formatting operations. I think it is still true, as per above. > Additionally, I have heard tell that one of the original inspirations for Python's significant whitespace code were C bugs caused by programmers who omitted braces and relied on indentation for if statements. In other words, code like the goto fail bug. Swift already takes care of this by making the curly braces mandatory in if statements, so Swift code will not fall victim to the class of bugs that inspired significant whitespace. I think that if you know from the outset that whitespace is semantic in a given language, such bugs are no more likely than mismatched brace problems. > Python on the other hand, is vulnerable to this kind of bug due to unintentional outdenting. Maybe a programmer, when moving a block, missed intending the last line of the block. Perhaps an errant finger hit the delete key, outdenting the last line of an if statement. Python will now execute this line unconditionally. The equivalent error in braces-based languages, accidentally deleting the closing brace, will just cause the code to not compile. This has never personally happened to me in all my Python coding… though related issues like forgetting to indent are caught by the Python compiler, since empty blocks are not allowed (there’s the `pass` statement of course). It’s well worth my Python code being more readable and prettier, in any case. ---
**Author:** ![Andrey\_Tarantsov](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/andrey_tarantsov/32/9434_2.png) [@Andrey\_Tarantsov](https://forums.swift.org/u/Andrey_Tarantsov)\ **Post date:** [December 20, 2015, 8:33pm UTC](https://forums.swift.org/t/brace-syntax/678/28 "2015-12-20T20:33:49Z")
We're really wasting time here (I'm pretty sure that the core team isn't considering the possibility), but: > You could try to prevent this is Swift by banning the use of either tabs or spaces in indentation. But this would put you in the middle of a holy war [...] Go does just that, with great profit. (gofmt turns all indentation into tabs, although I would argue that a better approach is to ban tabs and only ever allow spaces) > Critics of [braces] tend to focus on the fact that they don't express anything not already expressed by indentation. But as I've explained here, that's not quite true. They provide enough context to text editors to automatically format your code for you. Without them, text editors cannot perform certain formatting operations. Your whole point is that indentation sometimes gets lost on copy/paste, and braces don't. But it's a strange argument. Why would you use an editor or email program that routinely loses your data (indentation in this case)? Why would you copy your code from a strange web page whose author didn't even bother to format it correctly? It sounds like you're not using per-line copy/paste features in your editor, and you need to change your editor or editing habits. But I take the resulting broader point: indentation-based editing skills are a bit harder to master. > Python on the other hand, is vulnerable to this kind of bug due to unintentional outdenting. This is actually true. I've experienced this in Python a few times. Second valid point, I suppose, although it has never been a problem to catch it in practice. A. ---
**Author:** ![MichaelBuckley](https://avatars.discourse-cdn.com/v4/letter/m/7ab992/32.png) [@MichaelBuckley](https://forums.swift.org/u/MichaelBuckley)\ **Post date:** [December 20, 2015, 8:37pm UTC](https://forums.swift.org/t/brace-syntax/678/29 "2015-12-20T20:37:19Z")
> Thanks for sharing your thoughts. I hear what you’re saying, but not sure > any of these points are substantial enough to outweigh the benefits. And I think this is one of the most difficult aspects of discussing languages on this list. We're both looking at the issues from our own points of view, which are informed by our experiences, and neither of us can't rightly say, "your experience is invalid". The truth of the matter is, we lack any empiric evidence on which to base our decisions. Do braces hinder readability? You might say yes, I would say no. Again, we disagree, but without a large-scale analysis of these types of bugs in languages with braces vs. those without, we have nothing but our own experiences to go on, and our experiences may not be representative of the programming community at large. That's a long-winded way of saying that, while you may not think any of these points are substantial enough to outweigh the benefits, I don't see any benefits to be outweighed. I'm receptive to the argument that redundant and unnecessary features should be removed from the language, but from my point of view, braces provide value with no downsides. > I think the best and simplest solution for this is just to force tabs to > be used for semantic indentation, and disallow spaces. I believe F# does > this (and also allows optional spaces which are ignored) – though that > could have changed since I last used it. Golang did something similar a while back. The go-fmt tool indents everything with tabs. There was some grumbling about this, but my impression was people got over it. > Is this really as big a problem as you make it out? Personally, as a > programmer, I \*like\* being constrained in these ways. If there’s only one > way to do something correctly, it saves me a potential headache. Also, I > thought tabs had won the war(!) It's a very, very large distraction. Programmers love to bikeshed. I get more than enough email on this list, and I shudder to think of the flood that would occur if the tabs-spaces war began in here. The war is not over. Just google tabs vs spaces and you'll still find that people are writing arguments about this in 2015. For reference, everything I have seen has indicated that spaces are more popular. PEP-8 even calls out spaces as the preferred indentation method in Python, so I found it interesting that, coming from a Python background, you thought tabs had won the war. It goes to show that, despite PEP-8, the Python community is still not unified on tabs or spaces. > **[PEP 8 -- Style Guide for Python Code](https://legacy.python.org/dev/peps/pep-0008/#tabs-or-spaces)** > > PEP 8 -- Style Guide for Python Code Two years ago, spaces were used three times more in Java projects on Github. > **[Popular Code Conventions on GitHub](https://haacked.com/archive/2013/09/17/popular-code-conventions-on-github.aspx/)** > > The first GitHub Data Challenge launched in 2012 and asked the following compelling question: what would you do with all this data about our coding habits? > This is not a significant issue for me. We can’t help other software being > stupid (or other languages having small deficiencies). I don’t think it > crops up enough anyway. This is a great example of my point about our different experiences. This crops up often for me, but not often for you. Who knows how big a problem this really is? Not I! > Additionally, I have heard tell that one of the original inspirations for > Python's significant whitespace code were C bugs caused by programmers who > omitted braces and relied on indentation for if statements. In other words, > code like the goto fail bug. Swift already takes care of this by making the > curly braces mandatory in if statements, so Swift code will not fall victim > to the class of bugs that inspired significant whitespace. > > I think that if you know from the outset that whitespace is semantic in a > given language, such bugs are no more likely than mismatched brace problems. No more likely, I agree, but my point is these bugs are more catastrophic in significant indentation languages. The entire reason why swift requires braces for even single-line statements is to avoid the kinds of bugs that caused the goto fail issue. This has never personally happened to me in all my Python coding… though > related issues like forgetting to indent are caught by the Python compiler, > since empty blocks are not allowed (there’s the `pass` statement of > course). It’s well worth my Python code being more readable and prettier, > in any case. And again, different experiences. This has happened to me a couple of times over the years. > **···** > > On Sun, Dec 20, 2015 at 11:46 AM, Alexander Regueiro \ wrote: ---
**Author:** ![MichaelBuckley](https://avatars.discourse-cdn.com/v4/letter/m/7ab992/32.png) [@MichaelBuckley](https://forums.swift.org/u/MichaelBuckley)\ **Post date:** [December 20, 2015, 8:47pm UTC](https://forums.swift.org/t/brace-syntax/678/30 "2015-12-20T20:47:06Z")
Yeah, good point. But since I'm writing Swift code, I'm going to use Xcode. And with apologies to users of other editors, I suspect 99% of swift code will be written in Xcode, so it's probably worth considering how Xcode will deal with copy-paste. But for Python, I could use a different editor. As for why I would accept such poorly-formatted code, the exact scenario I'm thinking of happened a few years ago. A colleague went on vacation and realized one of the functions he had written had a bad bug in it. He couldn't get into the corporate network over VPN from his remote location, so he emailed me what the function should actually be and then disconnected himself from the Internet for a week. The problem was whatever email system he used to send the code mangled the indentation. It was quite an impressive feat. I suspect the more common use case is people copying and pasting poorly-formatted code off Stack Overflow. > **···** > > On Sun, Dec 20, 2015 at 12:33 PM, Andrey Tarantsov \ wrote: > > > Your whole point is that indentation sometimes gets lost on copy/paste, > > and braces don't. But it's a strange argument. Why would you use an editor > > or email program that routinely loses your data (indentation in this case)? > > Why would you copy your code from a strange web page whose author didn't > > even bother to format it correctly? > > > > It sounds like you're not using per-line copy/paste features in your > > editor, and you need to change your editor or editing habits. > > > > But I take the resulting broader point: indentation-based editing skills > > are a bit harder to master. ---
**Author:** ![alexreg](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/alexreg/32/12360_2.png) [@alexreg](https://forums.swift.org/u/alexreg)\ **Post date:** [December 20, 2015, 8:36pm UTC](https://forums.swift.org/t/brace-syntax/678/31 "2015-12-20T20:36:26Z")
How can we find out if the core team is willing to consider this? Do we know their original rationale for choosing braces? The reason I proposed this in the first place was because I suspected they’d just chosen them by default (given that Swift was inspired to large extends by Objective C and C#). > **···** > > > On 20 Dec 2015, at 20:33, Andrey Tarantsov \ wrote: > > > > We're really wasting time here (I'm pretty sure that the core team isn't considering the possibility), but: > > > > > You could try to prevent this is Swift by banning the use of either tabs or spaces in indentation. But this would put you in the middle of a holy war [...] > > > > Go does just that, with great profit. > > > > (gofmt turns all indentation into tabs, although I would argue that a better approach is to ban tabs and only ever allow spaces) > > > > > Critics of [braces] tend to focus on the fact that they don't express anything not already expressed by indentation. But as I've explained here, that's not quite true. They provide enough context to text editors to automatically format your code for you. Without them, text editors cannot perform certain formatting operations. > > > > Your whole point is that indentation sometimes gets lost on copy/paste, and braces don't. But it's a strange argument. Why would you use an editor or email program that routinely loses your data (indentation in this case)? Why would you copy your code from a strange web page whose author didn't even bother to format it correctly? > > > > It sounds like you're not using per-line copy/paste features in your editor, and you need to change your editor or editing habits. > > > > But I take the resulting broader point: indentation-based editing skills are a bit harder to master. > > > > > Python on the other hand, is vulnerable to this kind of bug due to unintentional outdenting. > > > > This is actually true. I've experienced this in Python a few times. Second valid point, I suppose, although it has never been a problem to catch it in practice. > > > > A. ---
**Author:** ![alexreg](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/alexreg/32/12360_2.png) [@alexreg](https://forums.swift.org/u/alexreg)\ **Post date:** [December 20, 2015, 8:50pm UTC](https://forums.swift.org/t/brace-syntax/678/32 "2015-12-20T20:50:17Z")
That’s true, we are discussing a rather subjective point here. At the end of the day, it will probably come down to personal preferences of the core team members. I haven’t yet seen a good argument against the ‘redundancy’ point I (and a couple of others) have made, but then again what others consider a ‘good’ argument seems to differ. Perhaps the best argument is that the redundancy is worth it for other reasons (easier to spot scoping errors?). Regarding tabs vs. spaces, I was only kidding around really. The (!) was meant to indicate that, sorry for not being clear! I’ve done a fair amount of Python, but actually come from more of a C/C# background. My personal preference is tabs, but wouldn’t like to claim the same of the community. We don’t want to start up the war here, like you say. I’ll be honest, I do like that Swift requires braces for single-line statements. It introduces a level of consistency that makes me reasonably happy (given that I have to tolerate braces anyway). > **···** > > > On 20 Dec 2015, at 20:37, Michael Buckley \ wrote: > > > > On Sun, Dec 20, 2015 at 11:46 AM, Alexander Regueiro \\> wrote: > > Thanks for sharing your thoughts. I hear what you’re saying, but not sure any of these points are substantial enough to outweigh the benefits. > > > > And I think this is one of the most difficult aspects of discussing languages on this list. We're both looking at the issues from our own points of view, which are informed by our experiences, and neither of us can't rightly say, "your experience is invalid". The truth of the matter is, we lack any empiric evidence on which to base our decisions. Do braces hinder readability? You might say yes, I would say no. Again, we disagree, but without a large-scale analysis of these types of bugs in languages with braces vs. those without, we have nothing but our own experiences to go on, and our experiences may not be representative of the programming community at large. > > > > That's a long-winded way of saying that, while you may not think any of these points are substantial enough to outweigh the benefits, I don't see any benefits to be outweighed. I'm receptive to the argument that redundant and unnecessary features should be removed from the language, but from my point of view, braces provide value with no downsides. > > > > I think the best and simplest solution for this is just to force tabs to be used for semantic indentation, and disallow spaces. I believe F# does this (and also allows optional spaces which are ignored) – though that could have changed since I last used it. > > > > Golang did something similar a while back. The go-fmt tool indents everything with tabs. There was some grumbling about this, but my impression was people got over it. > > > > Is this really as big a problem as you make it out? Personally, as a programmer, I \*like\* being constrained in these ways. If there’s only one way to do something correctly, it saves me a potential headache. Also, I thought tabs had won the war(!) > > > > It's a very, very large distraction. Programmers love to bikeshed. I get more than enough email on this list, and I shudder to think of the flood that would occur if the tabs-spaces war began in here. The war is not over. Just google tabs vs spaces and you'll still find that people are writing arguments about this in 2015. > > > > For reference, everything I have seen has indicated that spaces are more popular. PEP-8 even calls out spaces as the preferred indentation method in Python, so I found it interesting that, coming from a Python background, you thought tabs had won the war. It goes to show that, despite PEP-8, the Python community is still not unified on tabs or spaces. > > > > [http://legacy.python.org/dev/peps/pep-0008/#tabs-or-spaces](http://legacy.python.org/dev/peps/pep-0008/#tabs-or-spaces) > > > > Two years ago, spaces were used three times more in Java projects on Github. > > > > [Popular Code Conventions on GitHub | You’ve Been Haacked](http://haacked.com/archive/2013/09/17/popular-code-conventions-on-github.aspx/) > > > > This is not a significant issue for me. We can’t help other software being stupid (or other languages having small deficiencies). I don’t think it crops up enough anyway. > > > > This is a great example of my point about our different experiences. This crops up often for me, but not often for you. Who knows how big a problem this really is? Not I! > > > > \> Additionally, I have heard tell that one of the original inspirations for Python's significant whitespace code were C bugs caused by programmers who omitted braces and relied on indentation for if statements. In other words, code like the goto fail bug. Swift already takes care of this by making the curly braces mandatory in if statements, so Swift code will not fall victim to the class of bugs that inspired significant whitespace. > > > > I think that if you know from the outset that whitespace is semantic in a given language, such bugs are no more likely than mismatched brace problems. > > > > No more likely, I agree, but my point is these bugs are more catastrophic in significant indentation languages. The entire reason why swift requires braces for even single-line statements is to avoid the kinds of bugs that caused the goto fail issue. > > > > This has never personally happened to me in all my Python coding… though related issues like forgetting to indent are caught by the Python compiler, since empty blocks are not allowed (there’s the `pass` statement of course). It’s well worth my Python code being more readable and prettier, in any case. > > > > And again, different experiences. This has happened to me a couple of times over the years. ---
**Author:** ![Andrey\_Tarantsov](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/andrey_tarantsov/32/9434_2.png) [@Andrey\_Tarantsov](https://forums.swift.org/u/Andrey_Tarantsov)\ **Post date:** [December 20, 2015, 8:37pm UTC](https://forums.swift.org/t/brace-syntax/678/33 "2015-12-20T20:37:34Z")
> How can we find out if the core team is willing to consider this? Well, for example: > I do agree that there are some benefits to ditching braces and relying on indentation instead, but there are also downsides. Deviating from the C family in this respect would have to provide \*overwhelmingly\* large advantages for us to take such a plunge, and they simply don’t exist. > > -Chris A. ---
**Author:** ![Austin](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/austin/32/1196_2.png) [@Austin](https://forums.swift.org/u/Austin)\ **Post date:** [December 20, 2015, 8:45pm UTC](https://forums.swift.org/t/brace-syntax/678/34 "2015-12-20T20:45:40Z")
It's been mentioned in a few other threads, but it would be nice to have a FAQ somewhere listing common things that people are likely to ask for, and what sort of burden of proof they should bring to the table if they want to make a proposal about those things. This would prevent us from having perennially recurring (and increasingly useless) discussions, while also leaving the door open for people who really do have groundbreaking new arguments for e.g. whitespace vs braces. Austin > **···** > > > On Dec 20, 2015, at 12:37 PM, Andrey Tarantsov via swift-evolution \ wrote: > > > > > How can we find out if the core team is willing to consider this? > > > > Well, for example: > > > > > I do agree that there are some benefits to ditching braces and relying on indentation instead, but there are also downsides. Deviating from the C family in this respect would have to provide \*overwhelmingly\* large advantages for us to take such a plunge, and they simply don’t exist. > > > > > > -Chris > > > > A. > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\ **Post date:** [December 20, 2015, 9:34pm UTC](https://forums.swift.org/t/brace-syntax/678/35 "2015-12-20T21:34:20Z")
You're right that this has been requested elsewhere; it's currently on me to get some basic structure for a "commonly requested changes" page into the swift-evolution repo so we can track such things. > **···** > > Sent from my iPhone > > > On Dec 20, 2015, at 12:45 PM, Austin Zheng via swift-evolution \ wrote: > > > > It's been mentioned in a few other threads, but it would be nice to have a FAQ somewhere listing common things that people are likely to ask for, and what sort of burden of proof they should bring to the table if they want to make a proposal about those things. > > > > This would prevent us from having perennially recurring (and increasingly useless) discussions, while also leaving the door open for people who really do have groundbreaking new arguments for e.g. whitespace vs braces. > > > > Austin > > > > > > On Dec 20, 2015, at 12:37 PM, Andrey Tarantsov via swift-evolution \ wrote: > > > > > > > > How can we find out if the core team is willing to consider this? > > > > > > Well, for example: > > > > > > > I do agree that there are some benefits to ditching braces and relying on indentation instead, but there are also downsides. Deviating from the C family in this respect would have to provide \*overwhelmingly\* large advantages for us to take such a plunge, and they simply don’t exist. > > > > > > > > -Chris > > > > > > A. > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![possen](https://avatars.discourse-cdn.com/v4/letter/p/ed8c4c/32.png) [@possen](https://forums.swift.org/u/possen)\ **Post date:** [December 21, 2015, 2:53am UTC](https://forums.swift.org/t/brace-syntax/678/36 "2015-12-21T02:53:09Z")
I agree, there is no need to change this. Braces are fine. Even if they are recommended at the end of the line, prior to Swift I was a firm believer in the one-true-brace style (i.e. aligned) but I prefer to have the defacto standard present in Swift. It turns out it is fine and does not bother me now that I am used to it. Was initially maybe wishing it was no braces? Yes, but I think it was the right decision in the end. If we change it, some people will be annoyed that it changed other will will be happy, I doubt there can can be any agreement to change it. One advantage of being on the core team that designed the language prior to open sourcing it, is that you get to make decisions like this. I am sure they were quite aware of Python and every other language out there and decided to go with this approach. This may sound a bit ironic coming from a guy who wants to replace ternary, and it is not a bad thing to revisit things if they are truly going to make things better but I think what I am suggesting actually could be more powerful and useful. Changing the brace style does not improve anything it except level of clutter, after that, it is more of personal preference. Further, I used to be in firmly in the tab camp but now, I find I don’t care and actually prefer spaces. - Paul > **···** > > > On Dec 20, 2015, at 1:34 PM, Douglas Gregor via swift-evolution \ wrote: > > > > You're right that this has been requested elsewhere; it's currently on me to get some basic structure for a "commonly requested changes" page into the swift-evolution repo so we can track such things. > > > > Sent from my iPhone > > > > > On Dec 20, 2015, at 12:45 PM, Austin Zheng via swift-evolution \ wrote: > > > > > > It's been mentioned in a few other threads, but it would be nice to have a FAQ somewhere listing common things that people are likely to ask for, and what sort of burden of proof they should bring to the table if they want to make a proposal about those things. > > > > > > This would prevent us from having perennially recurring (and increasingly useless) discussions, while also leaving the door open for people who really do have groundbreaking new arguments for e.g. whitespace vs braces. > > > > > > Austin > > > > > > > > On Dec 20, 2015, at 12:37 PM, Andrey Tarantsov via swift-evolution \ wrote: > > > > > > > > > > How can we find out if the core team is willing to consider this? > > > > > > > > Well, for example: > > > > > > > > > I do agree that there are some benefits to ditching braces and relying on indentation instead, but there are also downsides. Deviating from the C family in this respect would have to provide \*overwhelmingly\* large advantages for us to take such a plunge, and they simply don’t exist. > > > > > > > > > > -Chris > > > > > > > > A. > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > > > swift-evolution@swift.org > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) [Previous page](https://forums.swift.org/t/brace-syntax/678.md?page=1)