[swift-evolution] Brace syntax

[Alexander Regueiro]

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.