Re: [swift-evolution] Brace syntax

[Michael Buckley via swift-evolution]

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

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.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Brace syntax

[Charles Constant via swift-evolution]

> 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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Brace syntax

[Charles Constant via swift-evolution]

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

Re: [swift-evolution] Brace syntax

[Charles Constant via swift-evolution]

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 <2...@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

Re: [swift-evolution] Brace syntax

[Andrey Tarantsov via 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.

A.

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

Re: [swift-evolution] Brace syntax

[Rudolf Adamkovic via swift-evolution]

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

Re: [swift-evolution] Brace syntax

[Alexander Regueiro via 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  wrote:
> 
> 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 
> > 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 
> 
> 
> 
> ___
> 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

Re: [swift-evolution] Brace syntax

[Alexander Regueiro via 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 

[swift-evolution] Brace syntax

[Alexander Regueiro via swift-evolution]

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

Re: [swift-evolution] Brace syntax

[Charles Constant via swift-evolution]

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
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Brace syntax

[Kevin Ballard via swift-evolution]

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

Re: [swift-evolution] Brace syntax

[Andrew Bennett via swift-evolution]

-1 I agree with Charles, although Chris and Kevin made some pretty good
points too :)

On Sun, Dec 20, 2015 at 3:03 PM, Charles Srstka via swift-evolution <
swift-evolution@swift.org> wrote:

> On Dec 19, 2015, at 7: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.
>
>
> No. No no no no no no no. No. Please, no.
>
> -1.
>
> Charles
>
>
> ___
> 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

Re: [swift-evolution] Brace syntax

[Dennis Lysenko via swift-evolution]

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

Re: [swift-evolution] Brace syntax

[Craig Cruden via 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 
>  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

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

Re: [swift-evolution] Brace syntax

[Charles Srstka via swift-evolution]

> On Dec 19, 2015, at 7: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.

No. No no no no no no no. No. Please, no.

-1.

Charles

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

Re: [swift-evolution] Brace syntax

[Alexander Regueiro via swift-evolution]

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

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

Re: [swift-evolution] Brace syntax

[Chris Lattner via swift-evolution]

> On Dec 19, 2015, at 5:58 PM, Kevin Ballard via swift-evolution 
>  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 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Brace syntax

[Charles Constant via swift-evolution]

+1 fwiw

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