Has anyone considered removing braces from the Swift language? The main alternative would be indentation-based scoping like in Python or Ruby. There already seems to be a general emphasis on conciseness, lack of redundancy, and a modern syntax. e.g. semicolons are not required for single-line statements; brackets have been removed from if/for/while expressions, compared to C-style syntax. So, why not go the whole way in breaking the C-style connection? The present syntax seems to be shunning C, but only slightly.
There is not in fact an emphasis on conciseness. This has been repeated many times by the swift team. Conciseness is not a goal of Swift, but expressiveness absolutely is. Braces are a well-understood and simple way to express the notion of a scope/closure. And FWIW removing braces means you have to come up with a completely different syntax for closures, because indentation does not suffice there.
Also, "don't be like C" is not even remotely a goal of Swift. The Swift syntax is C-like in many respects. "Be like C" isn't a goal either of course, but when deciding between two alternatives that have no compelling arguments either way, picking the one that would be more familiar to Obj-C programmers is usually a good idea.
-Kevin Ballard
···
On Sat, Dec 19, 2015, at 05:39 PM, Alexander Regueiro via swift-evolution wrote:
Has anyone considered removing braces from the Swift language? The main alternative would be indentation-based scoping like in Python or Ruby. There already seems to be a general emphasis on conciseness, lack of redundancy, and a modern syntax. e.g. semicolons are not required for single-line statements; brackets have been removed from if/for/while expressions, compared to C-style syntax. So, why not go the whole way in breaking the C-style connection? The present syntax seems to be shunning C, but only slightly.
Kevin got it exactly right, but I’d expand that last bit a bit to:
“… picking the one that is most familiar to programmers in the extended C family is a good idea.
The extended C family of language (which includes C, C++, ObjC, but also C#, Java, Javascript, and more) is an extremely popular and widely used set of languages that have a lot of surface-level similarity. I don’t claim to know the design rationale of all of these languages, but I surmise that this is not an accident: programmers move around and work in different languages, and this allows a non-expert in the language to understand what is going on. While there are things about C that are really unfortunate IMO (e.g. the declarator/declaration specifier part of the grammar) there is a lot of goodness in the basic operator set, focus on dot syntax, and more.
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
···
On Dec 19, 2015, at 5:58 PM, Kevin Ballard via swift-evolution <swift-evolution@swift.org> wrote:
There is not in fact an emphasis on conciseness. This has been repeated many times by the swift team. Conciseness is not a goal of Swift, but expressiveness absolutely is. Braces are a well-understood and simple way to express the notion of a scope/closure. And FWIW removing braces means you have to come up with a completely different syntax for closures, because indentation does not suffice there.
Also, "don't be like C" is not even remotely a goal of Swift. The Swift syntax is C-like in many respects. "Be like C" isn't a goal either of course, but when deciding between two alternatives that have no compelling arguments either way, picking the one that would be more familiar to Obj-C programmers is usually a good idea.
Grr, I hate braces so much I can't even... but I've seen this discussed on
the Apple dev forums. It's not going to happen. I think the best we (those
of us who dislike braces) can ever hope for is that Xcode gives us a way to
view our code in the IDE as though braces didn't exists - even if the
underlying file uses them, and probably the clipboard so that the outside
world can have "one way" of writing Swift. I doubt that will happen either,
but it seems far more likely to me than that Swift will suddenly do a 180
on something I'm sure Chris and the rest considered at length already.
···
On Sat, Dec 19, 2015 at 5:39 PM, Alexander Regueiro via swift-evolution < swift-evolution@swift.org> wrote:
Has anyone considered removing braces from the Swift language? The main
alternative would be indentation-based scoping like in Python or Ruby.
There already seems to be a general emphasis on conciseness, lack of
redundancy, and a modern syntax. e.g. semicolons are not required for
single-line statements; brackets have been removed from if/for/while
expressions, compared to C-style syntax. So, why not go the whole way in
breaking the C-style connection? The present syntax seems to be shunning C,
but only slightly.
This entire thread is just beating dead horse. Having said that; why not
allow braces for closures, and disallow them elsewhere? It doesn't seem
like a deal-breaker, really. I don't think there's much to debate aside
from this: some people worry that significant whitespace makes code more
error-prone, and others feel the increased legibility makes it less
error-prone.
···
On Sat, Dec 19, 2015 at 5:58 PM, Kevin Ballard via swift-evolution < swift-evolution@swift.org> wrote:
There is not in fact an emphasis on conciseness. This has been repeated
many times by the swift team. Conciseness is not a goal of Swift, but
expressiveness absolutely is. Braces are a well-understood and simple way
to express the notion of a scope/closure. And FWIW removing braces means
you have to come up with a completely different syntax for closures,
because indentation does not suffice there.
Also, "don't be like C" is not even remotely a goal of Swift. The Swift
syntax is C-like in many respects. "Be like C" isn't a goal either of
course, but when deciding between two alternatives that have no compelling
arguments either way, picking the one that would be more familiar to Obj-C
programmers is usually a good idea.
-Kevin Ballard
On Sat, Dec 19, 2015, at 05:39 PM, Alexander Regueiro via swift-evolution > wrote:
> Has anyone considered removing braces from the Swift language? The main
alternative would be indentation-based scoping like in Python or Ruby.
There already seems to be a general emphasis on conciseness, lack of
redundancy, and a modern syntax. e.g. semicolons are not required for
single-line statements; brackets have been removed from if/for/while
expressions, compared to C-style syntax. So, why not go the whole way in
breaking the C-style connection? The present syntax seems to be shunning C,
but only slightly.
>
> Thoughts?
> _______________________________________________
> 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 have done a bunch of Python programming and when programming in Python I don’t find the lack of braces to be a problem most of the time, except occasionally if cutting and pasting code from web pages (then it is a huge pain).
I think Swift has this right though. In my mind, braces indicate groupings of statements. Making the use of them mandatory, I believe is also the right choice to avoid ambiguity as to whether the else clause goes with the inner if or the outer. I believe this discipline is good in that it avoids errors which are hard to detect. Finally, this enforces a consistency across all teams (despite my voting against required self). Being able to use more expressions and fewer statements may quell some people who hate lots of braces. Shameless plug for my new proposal on the ternary thread :-)
Further the statements vs expressions where statements are contained in braces and expressions have parenthesis, i think helps to subtly reinforce the differences between the two forms. This is why in my opinion, making statements into expressions is not a good direction for Swift as has been done in other languages, like Ruby. It complicates the programming model.
I feel like there is a discussion coming up with this soon as to whether statements and expressions should remain separate in Swift or the two should be combined. Haskell and other functional programming languages have blurred this line, but is it a good thing? In my experience with the ternary thread this came up quite a bit.
- Paul
···
On Dec 19, 2015, at 8:37 PM, Charles Constant via swift-evolution <swift-evolution@swift.org> wrote:
This entire thread is just beating dead horse. Having said that; why not allow braces for closures, and disallow them elsewhere? It doesn't seem like a deal-breaker, really. I don't think there's much to debate aside from this: some people worry that significant whitespace makes code more error-prone, and others feel the increased legibility makes it less error-prone.
On Sat, Dec 19, 2015 at 5:58 PM, Kevin Ballard via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
There is not in fact an emphasis on conciseness. This has been repeated many times by the swift team. Conciseness is not a goal of Swift, but expressiveness absolutely is. Braces are a well-understood and simple way to express the notion of a scope/closure. And FWIW removing braces means you have to come up with a completely different syntax for closures, because indentation does not suffice there.
Also, "don't be like C" is not even remotely a goal of Swift. The Swift syntax is C-like in many respects. "Be like C" isn't a goal either of course, but when deciding between two alternatives that have no compelling arguments either way, picking the one that would be more familiar to Obj-C programmers is usually a good idea.
-Kevin Ballard
On Sat, Dec 19, 2015, at 05:39 PM, Alexander Regueiro via swift-evolution wrote:
> Has anyone considered removing braces from the Swift language? The main alternative would be indentation-based scoping like in Python or Ruby. There already seems to be a general emphasis on conciseness, lack of redundancy, and a modern syntax. e.g. semicolons are not required for single-line statements; brackets have been removed from if/for/while expressions, compared to C-style syntax. So, why not go the whole way in breaking the C-style connection? The present syntax seems to be shunning C, but only slightly.
>
> Thoughts?
> _______________________________________________
> 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
Python started in 1990 and Ruby started in 1995. Java started in 1996; C# in 2000; Go in 2010. These languages all use braces and are more recent than Python and Ruby. ALGOL 60, where 60 stands for 1960, didn't use braces either.
To me, that's basically a fashion point. Given that this doesn't seem to open any new possibility over what we have, I wouldn't be in favor of it.
···
Le 19 déc. 2015 à 20:39:06, Alexander Regueiro via swift-evolution <swift-evolution@swift.org> a écrit :
Has anyone considered removing braces from the Swift language? The main alternative would be indentation-based scoping like in Python or Ruby. There already seems to be a general emphasis on conciseness, lack of redundancy, and a modern syntax. e.g. semicolons are not required for single-line statements; brackets have been removed from if/for/while expressions, compared to C-style syntax. So, why not go the whole way in breaking the C-style connection? The present syntax seems to be shunning C, but only slightly.
I think you miss my point. In any case, it’s more stylistic consistency than fashion. Also, who wants to type braces? Your current philosophy seems to be to towards minimising syntax. So surely this is a matter of being consistent?
Also, if indenting code is good (universal) practice, and makes braces redundant without loss of readability, why keep them?
···
On 20 Dec 2015, at 02:24, Félix Cloutier <felixcca@yahoo.ca> wrote:
Python started in 1990 and Ruby started in 1995. Java started in 1996; C# in 2000; Go in 2010. These languages all use braces and are more recent than Python and Ruby. ALGOL 60, where 60 stands for 1960, didn't use braces either.
To me, that's basically a fashion point. Given that this doesn't seem to open any new possibility over what we have, I wouldn't be in favor of it.
Le 19 déc. 2015 à 20:39:06, Alexander Regueiro via swift-evolution <swift-evolution@swift.org> a écrit :
Has anyone considered removing braces from the Swift language? The main alternative would be indentation-based scoping like in Python or Ruby. There already seems to be a general emphasis on conciseness, lack of redundancy, and a modern syntax. e.g. semicolons are not required for single-line statements; brackets have been removed from if/for/while expressions, compared to C-style syntax. So, why not go the whole way in breaking the C-style connection? The present syntax seems to be shunning C, but only slightly.
Also, Ruby has braces, though it is generally stylistically suggested to
only use them for inline blocks (arr.map { |x| x.name.chars.first }) and
when you don't use braces, you use even more verbose `do`/`end` syntax.
I don't know many people who have experienced a large variety (8+?) of
programming languages and prefer Python's forced indentation, but that's
just a point of style. Generally, I agree with all the stated points about
why braces are used, and Swift really seems to have been built with them in
mind.
···
On Sat, Dec 19, 2015 at 9:24 PM Félix Cloutier <swift-evolution@swift.org> wrote:
Python started in 1990 and Ruby started in 1995. Java started in 1996; C#
in 2000; Go in 2010. These languages all use braces and are more recent
than Python and Ruby. ALGOL 60, where 60 stands for 1960, didn't use braces
either.
To me, that's basically a fashion point. Given that this doesn't seem to
open any new possibility over what we have, I wouldn't be in favor of it.
> Le 19 déc. 2015 à 20:39:06, Alexander Regueiro via swift-evolution < > swift-evolution@swift.org> a écrit :
>
> Has anyone considered removing braces from the Swift language? The main
alternative would be indentation-based scoping like in Python or Ruby.
There already seems to be a general emphasis on conciseness, lack of
redundancy, and a modern syntax. e.g. semicolons are not required for
single-line statements; brackets have been removed from if/for/while
expressions, compared to C-style syntax. So, why not go the whole way in
breaking the C-style connection? The present syntax seems to be shunning C,
but only slightly.
>
> Thoughts?
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
Removing braces for scope would cause more problems than whatever you would gain from it - it is one character at the end of a function declaration and one at the end of a function.
Using white space to (indentation sometimes is a tab, sometimes and sometimes get mixed up) scope is not the best way to do it.
-1
···
On 2015-12-20, at 8:58:02, Kevin Ballard via swift-evolution <swift-evolution@swift.org> wrote:
There is not in fact an emphasis on conciseness. This has been repeated many times by the swift team. Conciseness is not a goal of Swift, but expressiveness absolutely is. Braces are a well-understood and simple way to express the notion of a scope/closure. And FWIW removing braces means you have to come up with a completely different syntax for closures, because indentation does not suffice there.
Also, "don't be like C" is not even remotely a goal of Swift. The Swift syntax is C-like in many respects. "Be like C" isn't a goal either of course, but when deciding between two alternatives that have no compelling arguments either way, picking the one that would be more familiar to Obj-C programmers is usually a good idea.
-Kevin Ballard
On Sat, Dec 19, 2015, at 05:39 PM, Alexander Regueiro via swift-evolution wrote:
Has anyone considered removing braces from the Swift language? The main alternative would be indentation-based scoping like in Python or Ruby. There already seems to be a general emphasis on conciseness, lack of redundancy, and a modern syntax. e.g. semicolons are not required for single-line statements; brackets have been removed from if/for/while expressions, compared to C-style syntax. So, why not go the whole way in breaking the C-style connection? The present syntax seems to be shunning C, but only slightly.
-1.
Please no. I've written a lot of Python. I much prefer Swift's strict
brace requirement.
···
On Sat, Dec 19, 2015 at 6:39 PM, Alexander Regueiro via swift-evolution <swift-evolution@swift.org> wrote:
Has anyone considered removing braces from the Swift language?
The main alternative would be indentation-based scoping like in Python
or Ruby. There already seems to be a general emphasis on conciseness,
lack of redundancy, and a modern syntax. e.g. semicolons are not
required for single-line statements; brackets have been removed
from if/for/while expressions, compared to C-style syntax. So, why
not go the whole way in breaking the C-style connection?
The present syntax seems to be shunning C, but only slightly.
But it's interesting to see that there are many wishes that could be addressed quite easily by the IDE:
Mandatory self, braces, optional return keyword… just not sure weather it would be good to put more complexity into Xcode than into the compiler ;-)
+1 for significant whitespace instead of braces. But as others said, ain't gonna happen... :(
···
Sent from my iPhone
On 20 Dec 2015, at 02:39, Alexander Regueiro via swift-evolution <swift-evolution@swift.org> wrote:
Has anyone considered removing braces from the Swift language? The main alternative would be indentation-based scoping like in Python or Ruby. There already seems to be a general emphasis on conciseness, lack of redundancy, and a modern syntax. e.g. semicolons are not required for single-line statements; brackets have been removed from if/for/while expressions, compared to C-style syntax. So, why not go the whole way in breaking the C-style connection? The present syntax seems to be shunning C, but only slightly.
Honestly? Who cares? This doesn’t seem like a reasonable conversation to have, especially 1.5 years into Swift’s existence.
Having done a lot of work in Objective C (C-style braces), Ruby (newline, end), and CoffeeScript (significant whitespace), I couldn’t be less bothered with Swift’s choice of curly braces.
To me, the problem with C-style syntax are things like unnecessary parentheses and semicolons. Swift has neither of those. Comparing {} and Ruby style, I could go either way, it doesn’t really matter. Ruby is hardly less characters, just different and less symbols. Also has advantage that {} in blocks is separate from scoping. OTOH, symbolic {} is easier to discern and very clearly shows scopes.
Significant whitespace is very neat, but many a times I was confused by it, and made a mistake, or was close to making a mistake, because scopes just weren’t clearly defined enough. I like it, but I can definitely see downsides.
</bikeshed>
— Radek
···
On 20 Dec 2015, at 02:39, Alexander Regueiro via swift-evolution <swift-evolution@swift.org> wrote:
Has anyone considered removing braces from the Swift language? The main alternative would be indentation-based scoping like in Python or Ruby. There already seems to be a general emphasis on conciseness, lack of redundancy, and a modern syntax. e.g. semicolons are not required for single-line statements; brackets have been removed from if/for/while expressions, compared to C-style syntax. So, why not go the whole way in breaking the C-style connection? The present syntax seems to be shunning C, but only slightly.
just not sure weather it would be good to put more complexity into Xcode
Braceless mode is sort of a special case. It could be useful, even for
people prefer braces, to temporarily hide some of the more, uh, decorative
elements - and vice versa.
The option to switch back and forth, for braces/significant whitespace is
helpful to both sides. As much as I like Python, it would be cool to be
able to "turn on braces" and double-check some section of my code with an
unusually high number of indentations. Likewise, I can imagine it being
useful to get rid of some vertical space for someone who otherwise likes
braces - e.g.: to scan through a Class that has a large number of getters /
setters (which just love to barf out newlines with braces in Swift).
And it would be quite like Apple to brand it "Pseudo-Code View" or
something.
···
On Sun, Dec 20, 2015 at 3:48 AM, Tino Heth via swift-evolution < swift-evolution@swift.org> wrote:
-1, I like braces
But it's interesting to see that there are many wishes that could be
addressed quite easily by the IDE:
Mandatory self, braces, optional return keyword… just not sure weather it
would be good to put more complexity into Xcode than into the compiler ;-)
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
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.
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:
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.
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?
;-)