Brace syntax

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?

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 <dennis.s.lysenko@gmail.com> wrote:

Contrived example Charles. Apple's tutorials consistently put braces on
the line of the statement declaration.
The Swift Programming Language: Redirect

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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

var foo: Int
{
    get
    {
        return _foo
    }
    set
    {
        _foo = newValue
    }
}

I assume you know that braces don't require an extra line for themselves? ;-)

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 < 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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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 <swift-evolution@swift.org> 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 <mailto: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

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@gmail.com> wrote:

Contrived example Charles. Apple's tutorials consistently put braces on the line of the statement declaration. The Swift Programming Language: Redirect

On Sun, Dec 20, 2015 at 7:16 AM Charles Constant via swift-evolution <swift-evolution@swift.org <mailto: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 <mailto: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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

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.

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.

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.

Two years ago, spaces were used three times more in Java projects on Github.

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 <alexreg@gmail.com> wrote:

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 <andrey@tarantsov.com> 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.

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 <andrey@tarantsov.com> 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.

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 <michael@buckleyisms.com> wrote:

On Sun, Dec 20, 2015 at 11:46 AM, Alexander Regueiro <alexreg@gmail.com <mailto:alexreg@gmail.com>> 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

Two years ago, spaces were used three times more in Java projects on Github.

Popular Code Conventions on GitHub | You’ve Been Haacked

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.

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.

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 <swift-evolution@swift.org> 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

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 <swift-evolution@swift.org> 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 <swift-evolution@swift.org> 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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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 <swift-evolution@swift.org> 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 <swift-evolution@swift.org> 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 <swift-evolution@swift.org> 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

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution