[swift-evolution] Brace syntax
michael at buckleyisms.com
Sun Dec 20 14:37:19 CST 2015
On Sun, Dec 20, 2015 at 11:46 AM, Alexander Regueiro <alexreg at gmail.com>
> 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution