[Idea] Wrap switch cases in curly braces


(James Froggatt) #1

While I'm not keen on introducing braces, your comparison to property getters and setters is a good one. This is an inconsistency.

To be honest, I wouldn't mind putting up with braces for a while, with the promise that we'll get a lightweight alternative to the switch statement, like the ternary operator is to if statements.
I feel like I use switch much more often to initialise a variable, or return a value, than I do to branch program logic (especially working with with enums), and it already seems a very heavy construct in these cases.

------------ Begin Message ------------
Group: gmane.comp.lang.swift.evolution
MsgID: <0C3EC993-9320-4F4C-B2AA-66967BEDFFED@gmail.com>

The discussion so far has given me a chance to organize my thinking, so here’s a more complete train of thought.

I get that people don’t like extra punctuation. The commonly rejected proposals, however, make it clear that braces are here to stay and we should be designing the syntax right now with that in mind. It took me a long time to get used to not using them in Python, now I’m getting used to using them again in Swift. Swift has a long life ahead of it, and there are going to be plenty of places where the syntax is going to become inconsistent in the service of supporting new features. Now is when we set the starting point though and try to set ourselves up in a way that requires a minimum of syntax goofs in the future.

―=Philosophy=―

As philosophical backdrop, here’s the link on removing braces in the “commonly rejected proposals” section:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003656.html

I’ll pull out two quotes from that post, one from Kevin Ballard:
"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 another edited as suggested by Chris Lattner:
"'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 is most familiar to programmers in the extended C family is a good idea."

So, from that I take:
1) braces indicate scoping
2) conciseness isn’t an end in itself
3) we should err on the side of being Cish when no other arguments prevail.

―=In C `cases` Aren’t Scopes, in Swift They Are=―

Starting from what’s Cish, here’s a snippet of Swift code:

let x=5
switch x {
  case 3:
    let y=5
    print(x," ",y)

  case 5:
    print("Two",x,"s”)

  default:
    print(“default")
}

This runs fine and prints “Two 5 s” to the console.

This is something similar in C:

int x=5;
switch (x) {
  case 3:
    int y=5;
    printf("%d %d",x,y);
    break;

  case 5:
    printf("Two %d s",x);
    break;

  default:
    printf(“default");
}

This code fails. C gives me an error pointing at `int y=5;` complaining that it expected an expression there. C++ gives me an error that it can’t jump to `case 5:` because it would skip over the declaration of `y`.

I can fix this in both C and C++ by wrapping the `case 3:` in curly braces, creating a local scope:

int x=5;
switch (x) {
  case 3: {
    int y=5;
    printf("%d %d",x,y);
    break;
  }

  case 5:
    printf("Two %d s",x);
    break;

  default:
    printf("default");
}

This code compiles fine in both C and C++. A new scope has been delimited and created, and `y` only exists in that scope.

So, by both criteria 1) and 3), Swift should be using braces on `case` statements. Each case is a scope unto itself, and the extended C family of languages would require braces in that event.

―=Conciseness, Ugliness and Nested Braces=―

Conciseness is not an emphasis of Swift, but even if it were then this is not a particularly in-concise change to the syntax. The suggestion here is to remove one punctuation mark and add two for a net gain of 1 character. This doesn’t strike me as unduly burdensome.

The better arguments are those on aesthetics and ease of use. Each of these seems to focus on opposite situations. The ugliness is when there is only one line per case, the ease of use challenge is when there are many and the developer needs to determine how many braces to close.

How common is it to have a single line per case?

Aesthetics, at least, are mostly subjective. Ease of use, in part, depends on habits. In both cases, however, I’d argue that the aesthetically preferable design, and the method least likely to introduce errors, is the one that is most consistent with the rest of the language. Things tend to be uglier when they stand out as unusual, and habits force us to follow patterns, introducing errors when the pattern doesn’t hold.

From that perspective, this is what Swift looks like everywhere else:

if x = 3 { print(“Three”) }
else if x = 5 { print(“Five”) }
else { print(“Default”) }

It also doesn’t shy away from nested braces:

var x:Int {
  get { return _x }
  set { _x = newValue }
}

Aesthetically, is it less ugly to have some scopes require braces and others not? I really thought the square bracket messaging syntax of Obj-C was ugly until I got used to it because square brackets were for subscripting and looked “heavy” for method calls.

From an ease of use perspective, it is more likely to forget to add a closing brace when braces are used everywhere, or to accidentally add one in the one place they aren’t?

―=What Isn’t Like C Shouldn’t Look Like C=―

There’s also the point that `switch` statements in Swift aren’t the same as those in C. The different scoping rules are one difference. The lack of default fall through is another. And of course the additional capabilities of the `case` condition itself.

For those reasons, deviating from the C syntax might not only be justified, but desirable as a notational reminder that this isn’t your father’s `switch` statement. The closing brace in particular gives a visual cue that fall through isn’t going to happen.

―=Leaving the Door Open for a `switch` Expression=―

Another commonly rejected proposal is the request for a `switch` expression:
https://lists.swift.org/pipermail/swift-evolution/2015-December/000393.html

To my eyes, the rejection of this proposal is not as iron clad as the rejection of removing curly braces. Here’s a quote from Chris Lattner:

"FWIW, I (and many other people) would like to consider turning many statement-y things in swift into expressions. I’d love to see the weird ?: ternary operator get nuked and replaced with an if/else expression of some sort. This is an area that the apple team hasn’t had bandwidth to consider carefully.

That said, there are challenges here in the details. How will the grammar work?”

I think wrapping the `case` statements in curly braces in the statement version of `switch` gets us closer to a reasonable answer for how the grammar might work on an expression version: the expression version would be delimited with colons similar to how the ternary operator is.

Something like this might work:

let s:String? = switch x
                case 3: “Three”
                case 5: “Five”
                default: nil

In the expression, the `case` clauses don’t represent scopes and shouldn’t be curly braced so the colons give a nice syntactic distinction.

I’m not holding by breath for such a feature, but this change to the `switch` statement makes such a thing easier to adopt.

···

On Jul 10, 2016, at 13:37 , Dennis De Mars <demars@fractaldomains.com> wrote:

I don’t like this idea at all. The current switch syntax is really clean, one of the nicest parts of Swift, and this would really turn it into something messy.

I’ll make a possibly controversial statement here: one of the worst aspects of C syntax, which is unfortunately perpetuated by many modern languages, Swift included, is the use of curly braces everywhere to demarcate every kind of block: every control structure, every data structure and every function body.

This leads to a proliferation of nested braces which all have to be placed correctly in order for the code to be correct. Of course, we all use indentation to help manage this, but I think we all know that once the closing brace is sufficiently far from the opening brace, it becomes difficult to tell which brace matches which even with indentation. I think I spend a significant amount of my development time just eyeballing those closing braces. Of course, we also have editor features to help match them up but relying on such editor features might be an indication of a flaw in the language. At any rate, it impedes readability of the code, editor or no editor.

Not having the braces for each case is, to me, analogous to the way Swift removed the outermost parenthesis in the if statement conditional part. When you have a complex conditional expression with nested parentheses, removing that unnecessary outermost pair really improves readability (and reduces possibility of error). This can be done because the outermost parentheses aren’t really necessary to demarcate the boundaries of the expression.

Similarly, the case keywords in the switch statement sufficiently demarcate the extent of the statement block; it is unnecessary to toss in an extra pair of these brace characters that may already be heavily used in the statement block itself.

I think the extra burden on readability (and writability) of having the extra pair of nested braces is not justified by the desire for consistency. If consistency is so important, then rather than detracting from the quality of the switch statement by adding the braces, why don’t we improve the quality of the rest of the language by getting rid of some of those braces in the other constructs that use them! (Note: I don’t really expect that to happen…)

- Dennis D.

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

------------- End Message -------------

From James F


(G B) #2

I think the discussion on this has run its course and it sounds like there’s mixed feelings, but it’s mostly a matter of opinion between consistency and “ugliness”. As I understand it, the “socialization” process isn’t meant to reach consensus, but to hone the proposal (or abandon it if the feedback is overwhelmingly negative). I think my last formulation is probably as well formed as I’ll get with the idea, I think there’s still mixed feedback, and a review is the way to settle the differences of opinion.

I think a proposal like this is in scope for Swift 3, and this is probably the last reasonable opportunity to consider it for a while, is that correct?

If so, I’ll put together a formal proposal.

The general process is described here:
https://github.com/apple/swift-evolution/blob/master/process.md
but I just want to double check the process because I’m not terribly familiar with GitHub, pull requests, etc and want to avoid generating more noise than I need to:

I need to clone the swift-evolution repo
Create a local branch
Copy the proposal template, and edit it for the proposal
Push the branch (do I need special permissions for this, or can anyone push a branch?)
Flag the branch for a pull request

Presumably someone else along the line assigns it a number.

Anything else I need to consider?

···

On Jul 11, 2016, at 02:04 , James Froggatt via swift-evolution <swift-evolution@swift.org> wrote:

While I'm not keen on introducing braces, your comparison to property getters and setters is a good one. This is an inconsistency.

To be honest, I wouldn't mind putting up with braces for a while, with the promise that we'll get a lightweight alternative to the switch statement, like the ternary operator is to if statements.
I feel like I use switch much more often to initialise a variable, or return a value, than I do to branch program logic (especially working with with enums), and it already seems a very heavy construct in these cases.

------------ Begin Message ------------
Group: gmane.comp.lang.swift.evolution
MsgID: <0C3EC993-9320-4F4C-B2AA-66967BEDFFED@gmail.com>

The discussion so far has given me a chance to organize my thinking, so here’s a more complete train of thought.

I get that people don’t like extra punctuation. The commonly rejected proposals, however, make it clear that braces are here to stay and we should be designing the syntax right now with that in mind. It took me a long time to get used to not using them in Python, now I’m getting used to using them again in Swift. Swift has a long life ahead of it, and there are going to be plenty of places where the syntax is going to become inconsistent in the service of supporting new features. Now is when we set the starting point though and try to set ourselves up in a way that requires a minimum of syntax goofs in the future.

―=Philosophy=―

As philosophical backdrop, here’s the link on removing braces in the “commonly rejected proposals” section:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003656.html

I’ll pull out two quotes from that post, one from Kevin Ballard:
"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 another edited as suggested by Chris Lattner:
"'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 is most familiar to programmers in the extended C family is a good idea."

So, from that I take:
1) braces indicate scoping
2) conciseness isn’t an end in itself
3) we should err on the side of being Cish when no other arguments prevail.

―=In C `cases` Aren’t Scopes, in Swift They Are=―

Starting from what’s Cish, here’s a snippet of Swift code:

let x=5
switch x {
case 3:
   let y=5
   print(x," ",y)

case 5:
   print("Two",x,"s”)

default:
   print(“default")
}

This runs fine and prints “Two 5 s” to the console.

This is something similar in C:

int x=5;
switch (x) {
case 3:
   int y=5;
   printf("%d %d",x,y);
   break;

case 5:
   printf("Two %d s",x);
   break;

default:
   printf(“default");
}

This code fails. C gives me an error pointing at `int y=5;` complaining that it expected an expression there. C++ gives me an error that it can’t jump to `case 5:` because it would skip over the declaration of `y`.

I can fix this in both C and C++ by wrapping the `case 3:` in curly braces, creating a local scope:

int x=5;
switch (x) {
case 3: {
   int y=5;
   printf("%d %d",x,y);
   break;
}

case 5:
   printf("Two %d s",x);
   break;

default:
   printf("default");
}

This code compiles fine in both C and C++. A new scope has been delimited and created, and `y` only exists in that scope.

So, by both criteria 1) and 3), Swift should be using braces on `case` statements. Each case is a scope unto itself, and the extended C family of languages would require braces in that event.

―=Conciseness, Ugliness and Nested Braces=―

Conciseness is not an emphasis of Swift, but even if it were then this is not a particularly in-concise change to the syntax. The suggestion here is to remove one punctuation mark and add two for a net gain of 1 character. This doesn’t strike me as unduly burdensome.

The better arguments are those on aesthetics and ease of use. Each of these seems to focus on opposite situations. The ugliness is when there is only one line per case, the ease of use challenge is when there are many and the developer needs to determine how many braces to close.

How common is it to have a single line per case?

Aesthetics, at least, are mostly subjective. Ease of use, in part, depends on habits. In both cases, however, I’d argue that the aesthetically preferable design, and the method least likely to introduce errors, is the one that is most consistent with the rest of the language. Things tend to be uglier when they stand out as unusual, and habits force us to follow patterns, introducing errors when the pattern doesn’t hold.

From that perspective, this is what Swift looks like everywhere else:

if x = 3 { print(“Three”) }
else if x = 5 { print(“Five”) }
else { print(“Default”) }

It also doesn’t shy away from nested braces:

var x:Int {
get { return _x }
set { _x = newValue }
}

Aesthetically, is it less ugly to have some scopes require braces and others not? I really thought the square bracket messaging syntax of Obj-C was ugly until I got used to it because square brackets were for subscripting and looked “heavy” for method calls.

From an ease of use perspective, it is more likely to forget to add a closing brace when braces are used everywhere, or to accidentally add one in the one place they aren’t?

―=What Isn’t Like C Shouldn’t Look Like C=―

There’s also the point that `switch` statements in Swift aren’t the same as those in C. The different scoping rules are one difference. The lack of default fall through is another. And of course the additional capabilities of the `case` condition itself.

For those reasons, deviating from the C syntax might not only be justified, but desirable as a notational reminder that this isn’t your father’s `switch` statement. The closing brace in particular gives a visual cue that fall through isn’t going to happen.

―=Leaving the Door Open for a `switch` Expression=―

Another commonly rejected proposal is the request for a `switch` expression:
https://lists.swift.org/pipermail/swift-evolution/2015-December/000393.html

To my eyes, the rejection of this proposal is not as iron clad as the rejection of removing curly braces. Here’s a quote from Chris Lattner:

"FWIW, I (and many other people) would like to consider turning many statement-y things in swift into expressions. I’d love to see the weird ?: ternary operator get nuked and replaced with an if/else expression of some sort. This is an area that the apple team hasn’t had bandwidth to consider carefully.

That said, there are challenges here in the details. How will the grammar work?”

I think wrapping the `case` statements in curly braces in the statement version of `switch` gets us closer to a reasonable answer for how the grammar might work on an expression version: the expression version would be delimited with colons similar to how the ternary operator is.

Something like this might work:

let s:String? = switch x
               case 3: “Three”
               case 5: “Five”
               default: nil

In the expression, the `case` clauses don’t represent scopes and shouldn’t be curly braced so the colons give a nice syntactic distinction.

I’m not holding by breath for such a feature, but this change to the `switch` statement makes such a thing easier to adopt.

On Jul 10, 2016, at 13:37 , Dennis De Mars <demars@fractaldomains.com> wrote:

I don’t like this idea at all. The current switch syntax is really clean, one of the nicest parts of Swift, and this would really turn it into something messy.

I’ll make a possibly controversial statement here: one of the worst aspects of C syntax, which is unfortunately perpetuated by many modern languages, Swift included, is the use of curly braces everywhere to demarcate every kind of block: every control structure, every data structure and every function body.

This leads to a proliferation of nested braces which all have to be placed correctly in order for the code to be correct. Of course, we all use indentation to help manage this, but I think we all know that once the closing brace is sufficiently far from the opening brace, it becomes difficult to tell which brace matches which even with indentation. I think I spend a significant amount of my development time just eyeballing those closing braces. Of course, we also have editor features to help match them up but relying on such editor features might be an indication of a flaw in the language. At any rate, it impedes readability of the code, editor or no editor.

Not having the braces for each case is, to me, analogous to the way Swift removed the outermost parenthesis in the if statement conditional part. When you have a complex conditional expression with nested parentheses, removing that unnecessary outermost pair really improves readability (and reduces possibility of error). This can be done because the outermost parentheses aren’t really necessary to demarcate the boundaries of the expression.

Similarly, the case keywords in the switch statement sufficiently demarcate the extent of the statement block; it is unnecessary to toss in an extra pair of these brace characters that may already be heavily used in the statement block itself.

I think the extra burden on readability (and writability) of having the extra pair of nested braces is not justified by the desire for consistency. If consistency is so important, then rather than detracting from the quality of the switch statement by adding the braces, why don’t we improve the quality of the rest of the language by getting rid of some of those braces in the other constructs that use them! (Note: I don’t really expect that to happen…)

- Dennis D.

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

------------- End Message -------------

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


(Chéyo Jiménez) #3

I think this proposal is not

""better enough" for it to make sense to diverge from the precedent established by the C family of languages.”

And I think the same would go for this

“Swift is designed to feel like a member of the C family of languages. Switching keywords away from C precedent without strong motivation is a non-goal”

https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

I just don’t think we gain much by switching to curly braces.

I made a similar argument about getting rid of the elvis operator ( ?: ) because it used colons and question marks.

···

On Jul 17, 2016, at 2:27 PM, G B via swift-evolution <swift-evolution@swift.org> wrote:

I think the discussion on this has run its course and it sounds like there’s mixed feelings, but it’s mostly a matter of opinion between consistency and “ugliness”. As I understand it, the “socialization” process isn’t meant to reach consensus, but to hone the proposal (or abandon it if the feedback is overwhelmingly negative). I think my last formulation is probably as well formed as I’ll get with the idea, I think there’s still mixed feedback, and a review is the way to settle the differences of opinion.

I think a proposal like this is in scope for Swift 3, and this is probably the last reasonable opportunity to consider it for a while, is that correct?

If so, I’ll put together a formal proposal.

The general process is described here:
https://github.com/apple/swift-evolution/blob/master/process.md
but I just want to double check the process because I’m not terribly familiar with GitHub, pull requests, etc and want to avoid generating more noise than I need to:

I need to clone the swift-evolution repo
Create a local branch
Copy the proposal template, and edit it for the proposal
Push the branch (do I need special permissions for this, or can anyone push a branch?)
Flag the branch for a pull request

Presumably someone else along the line assigns it a number.

Anything else I need to consider?

On Jul 11, 2016, at 02:04 , James Froggatt via swift-evolution <swift-evolution@swift.org> wrote:

While I'm not keen on introducing braces, your comparison to property getters and setters is a good one. This is an inconsistency.

To be honest, I wouldn't mind putting up with braces for a while, with the promise that we'll get a lightweight alternative to the switch statement, like the ternary operator is to if statements.
I feel like I use switch much more often to initialise a variable, or return a value, than I do to branch program logic (especially working with with enums), and it already seems a very heavy construct in these cases.

------------ Begin Message ------------
Group: gmane.comp.lang.swift.evolution
MsgID: <0C3EC993-9320-4F4C-B2AA-66967BEDFFED@gmail.com>

The discussion so far has given me a chance to organize my thinking, so here’s a more complete train of thought.

I get that people don’t like extra punctuation. The commonly rejected proposals, however, make it clear that braces are here to stay and we should be designing the syntax right now with that in mind. It took me a long time to get used to not using them in Python, now I’m getting used to using them again in Swift. Swift has a long life ahead of it, and there are going to be plenty of places where the syntax is going to become inconsistent in the service of supporting new features. Now is when we set the starting point though and try to set ourselves up in a way that requires a minimum of syntax goofs in the future.

―=Philosophy=―

As philosophical backdrop, here’s the link on removing braces in the “commonly rejected proposals” section:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003656.html

I’ll pull out two quotes from that post, one from Kevin Ballard:
"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 another edited as suggested by Chris Lattner:
"'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 is most familiar to programmers in the extended C family is a good idea."

So, from that I take:
1) braces indicate scoping
2) conciseness isn’t an end in itself
3) we should err on the side of being Cish when no other arguments prevail.

―=In C `cases` Aren’t Scopes, in Swift They Are=―

Starting from what’s Cish, here’s a snippet of Swift code:

let x=5
switch x {
case 3:
  let y=5
  print(x," ",y)

case 5:
  print("Two",x,"s”)

default:
  print(“default")
}

This runs fine and prints “Two 5 s” to the console.

This is something similar in C:

int x=5;
switch (x) {
case 3:
  int y=5;
  printf("%d %d",x,y);
  break;

case 5:
  printf("Two %d s",x);
  break;

default:
  printf(“default");
}

This code fails. C gives me an error pointing at `int y=5;` complaining that it expected an expression there. C++ gives me an error that it can’t jump to `case 5:` because it would skip over the declaration of `y`.

I can fix this in both C and C++ by wrapping the `case 3:` in curly braces, creating a local scope:

int x=5;
switch (x) {
case 3: {
  int y=5;
  printf("%d %d",x,y);
  break;
}

case 5:
  printf("Two %d s",x);
  break;

default:
  printf("default");
}

This code compiles fine in both C and C++. A new scope has been delimited and created, and `y` only exists in that scope.

So, by both criteria 1) and 3), Swift should be using braces on `case` statements. Each case is a scope unto itself, and the extended C family of languages would require braces in that event.

―=Conciseness, Ugliness and Nested Braces=―

Conciseness is not an emphasis of Swift, but even if it were then this is not a particularly in-concise change to the syntax. The suggestion here is to remove one punctuation mark and add two for a net gain of 1 character. This doesn’t strike me as unduly burdensome.

The better arguments are those on aesthetics and ease of use. Each of these seems to focus on opposite situations. The ugliness is when there is only one line per case, the ease of use challenge is when there are many and the developer needs to determine how many braces to close.

How common is it to have a single line per case?

Aesthetics, at least, are mostly subjective. Ease of use, in part, depends on habits. In both cases, however, I’d argue that the aesthetically preferable design, and the method least likely to introduce errors, is the one that is most consistent with the rest of the language. Things tend to be uglier when they stand out as unusual, and habits force us to follow patterns, introducing errors when the pattern doesn’t hold.

From that perspective, this is what Swift looks like everywhere else:

if x = 3 { print(“Three”) }
else if x = 5 { print(“Five”) }
else { print(“Default”) }

It also doesn’t shy away from nested braces:

var x:Int {
get { return _x }
set { _x = newValue }
}

Aesthetically, is it less ugly to have some scopes require braces and others not? I really thought the square bracket messaging syntax of Obj-C was ugly until I got used to it because square brackets were for subscripting and looked “heavy” for method calls.

From an ease of use perspective, it is more likely to forget to add a closing brace when braces are used everywhere, or to accidentally add one in the one place they aren’t?

―=What Isn’t Like C Shouldn’t Look Like C=―

There’s also the point that `switch` statements in Swift aren’t the same as those in C. The different scoping rules are one difference. The lack of default fall through is another. And of course the additional capabilities of the `case` condition itself.

For those reasons, deviating from the C syntax might not only be justified, but desirable as a notational reminder that this isn’t your father’s `switch` statement. The closing brace in particular gives a visual cue that fall through isn’t going to happen.

―=Leaving the Door Open for a `switch` Expression=―

Another commonly rejected proposal is the request for a `switch` expression:
https://lists.swift.org/pipermail/swift-evolution/2015-December/000393.html

To my eyes, the rejection of this proposal is not as iron clad as the rejection of removing curly braces. Here’s a quote from Chris Lattner:

"FWIW, I (and many other people) would like to consider turning many statement-y things in swift into expressions. I’d love to see the weird ?: ternary operator get nuked and replaced with an if/else expression of some sort. This is an area that the apple team hasn’t had bandwidth to consider carefully.

That said, there are challenges here in the details. How will the grammar work?”

I think wrapping the `case` statements in curly braces in the statement version of `switch` gets us closer to a reasonable answer for how the grammar might work on an expression version: the expression version would be delimited with colons similar to how the ternary operator is.

Something like this might work:

let s:String? = switch x
              case 3: “Three”
              case 5: “Five”
              default: nil

In the expression, the `case` clauses don’t represent scopes and shouldn’t be curly braced so the colons give a nice syntactic distinction.

I’m not holding by breath for such a feature, but this change to the `switch` statement makes such a thing easier to adopt.

On Jul 10, 2016, at 13:37 , Dennis De Mars <demars@fractaldomains.com> wrote:

I don’t like this idea at all. The current switch syntax is really clean, one of the nicest parts of Swift, and this would really turn it into something messy.

I’ll make a possibly controversial statement here: one of the worst aspects of C syntax, which is unfortunately perpetuated by many modern languages, Swift included, is the use of curly braces everywhere to demarcate every kind of block: every control structure, every data structure and every function body.

This leads to a proliferation of nested braces which all have to be placed correctly in order for the code to be correct. Of course, we all use indentation to help manage this, but I think we all know that once the closing brace is sufficiently far from the opening brace, it becomes difficult to tell which brace matches which even with indentation. I think I spend a significant amount of my development time just eyeballing those closing braces. Of course, we also have editor features to help match them up but relying on such editor features might be an indication of a flaw in the language. At any rate, it impedes readability of the code, editor or no editor.

Not having the braces for each case is, to me, analogous to the way Swift removed the outermost parenthesis in the if statement conditional part. When you have a complex conditional expression with nested parentheses, removing that unnecessary outermost pair really improves readability (and reduces possibility of error). This can be done because the outermost parentheses aren’t really necessary to demarcate the boundaries of the expression.

Similarly, the case keywords in the switch statement sufficiently demarcate the extent of the statement block; it is unnecessary to toss in an extra pair of these brace characters that may already be heavily used in the statement block itself.

I think the extra burden on readability (and writability) of having the extra pair of nested braces is not justified by the desire for consistency. If consistency is so important, then rather than detracting from the quality of the switch statement by adding the braces, why don’t we improve the quality of the rest of the language by getting rid of some of those braces in the other constructs that use them! (Note: I don’t really expect that to happen…)

- Dennis D.

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

------------- End Message -------------

From James F
_______________________________________________
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


(Chris Lattner) #4

I agree. I don’t think this proposal is worth considering at this point.

-Chris

···

On Jul 17, 2016, at 10:07 PM, Jose Cheyo Jimenez via swift-evolution <swift-evolution@swift.org> wrote:

I think this proposal is not

""better enough" for it to make sense to diverge from the precedent established by the C family of languages.”

And I think the same would go for this

“Swift is designed to feel like a member of the C family of languages. Switching keywords away from C precedent without strong motivation is a non-goal”

https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

I just don’t think we gain much by switching to curly braces.


(Saagar Jha) #5

Was the problem with the ternary conditional operator that nothing could be
found to replace it? That doesn't seem to be the issue here.

···

On Mon, Jul 18, 2016 at 00:02 Jose Cheyo Jimenez via swift-evolution < swift-evolution@swift.org> wrote:

I think this proposal is not

""better enough" for it to make sense to diverge from the precedent
established by the C family of languages.”

And I think the same would go for this

“Swift is designed to feel like a member of the C family of languages.
Switching keywords away from C precedent without strong motivation is a
non-goal”

https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

I just don’t think we gain much by switching to curly braces.

I made a similar argument about getting rid of the elvis operator ( ?: )
because it used colons and question marks.

On Jul 17, 2016, at 2:27 PM, G B via swift-evolution < > swift-evolution@swift.org> wrote:

I think the discussion on this has run its course and it sounds like
there’s mixed feelings, but it’s mostly a matter of opinion between
consistency and “ugliness”. As I understand it, the “socialization”
process isn’t meant to reach consensus, but to hone the proposal (or
abandon it if the feedback is overwhelmingly negative). I think my last
formulation is probably as well formed as I’ll get with the idea, I think
there’s still mixed feedback, and a review is the way to settle the
differences of opinion.

I think a proposal like this is in scope for Swift 3, and this is probably
the last reasonable opportunity to consider it for a while, is that correct?

If so, I’ll put together a formal proposal.

The general process is described here:
https://github.com/apple/swift-evolution/blob/master/process.md
but I just want to double check the process because I’m not terribly
familiar with GitHub, pull requests, etc and want to avoid generating more
noise than I need to:

I need to clone the swift-evolution repo
Create a local branch
Copy the proposal template, and edit it for the proposal
Push the branch (do I need special permissions for this, or can anyone
push a branch?)
Flag the branch for a pull request

Presumably someone else along the line assigns it a number.

Anything else I need to consider?

On Jul 11, 2016, at 02:04 , James Froggatt via swift-evolution < > swift-evolution@swift.org> wrote:

While I'm not keen on introducing braces, your comparison to property
getters and setters is a good one. This is an inconsistency.

To be honest, I wouldn't mind putting up with braces for a while, with the
promise that we'll get a lightweight alternative to the switch statement,
like the ternary operator is to if statements.
I feel like I use switch much more often to initialise a variable, or
return a value, than I do to branch program logic (especially working with
with enums), and it already seems a very heavy construct in these cases.

------------ Begin Message ------------
Group: gmane.comp.lang.swift.evolution
MsgID: <0C3EC993-9320-4F4C-B2AA-66967BEDFFED@gmail.com>

The discussion so far has given me a chance to organize my thinking, so
here’s a more complete train of thought.

I get that people don’t like extra punctuation. The commonly rejected
proposals, however, make it clear that braces are here to stay and we
should be designing the syntax right now with that in mind. It took me a
long time to get used to not using them in Python, now I’m getting used to
using them again in Swift. Swift has a long life ahead of it, and there
are going to be plenty of places where the syntax is going to become
inconsistent in the service of supporting new features. Now is when we set
the starting point though and try to set ourselves up in a way that
requires a minimum of syntax goofs in the future.

―=Philosophy=―

As philosophical backdrop, here’s the link on removing braces in the
“commonly rejected proposals” section:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003656.html

I’ll pull out two quotes from that post, one from Kevin Ballard:
"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 another edited as suggested by Chris Lattner:
"'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 is most familiar to programmers in the extended C family is a good
idea."

So, from that I take:
1) braces indicate scoping
2) conciseness isn’t an end in itself
3) we should err on the side of being Cish when no other arguments prevail.

―=In C `cases` Aren’t Scopes, in Swift They Are=―

Starting from what’s Cish, here’s a snippet of Swift code:

let x=5
switch x {
case 3:
  let y=5
  print(x," ",y)

case 5:
  print("Two",x,"s”)

default:
  print(“default")
}

This runs fine and prints “Two 5 s” to the console.

This is something similar in C:

int x=5;
switch (x) {
case 3:
  int y=5;
  printf("%d %d",x,y);
  break;

case 5:
  printf("Two %d s",x);
  break;

default:
  printf(“default");
}

This code fails. C gives me an error pointing at `int y=5;` complaining
that it expected an expression there. C++ gives me an error that it can’t
jump to `case 5:` because it would skip over the declaration of `y`.

I can fix this in both C and C++ by wrapping the `case 3:` in curly
braces, creating a local scope:

int x=5;
switch (x) {
case 3: {
  int y=5;
  printf("%d %d",x,y);
  break;
}

case 5:
  printf("Two %d s",x);
  break;

default:
  printf("default");
}

This code compiles fine in both C and C++. A new scope has been delimited
and created, and `y` only exists in that scope.

So, by both criteria 1) and 3), Swift should be using braces on `case`
statements. Each case is a scope unto itself, and the extended C family of
languages would require braces in that event.

―=Conciseness, Ugliness and Nested Braces=―

Conciseness is not an emphasis of Swift, but even if it were then this is
not a particularly in-concise change to the syntax. The suggestion here is
to remove one punctuation mark and add two for a net gain of 1 character.
This doesn’t strike me as unduly burdensome.

The better arguments are those on aesthetics and ease of use. Each of
these seems to focus on opposite situations. The ugliness is when there is
only one line per case, the ease of use challenge is when there are many
and the developer needs to determine how many braces to close.

How common is it to have a single line per case?

Aesthetics, at least, are mostly subjective. Ease of use, in part,
depends on habits. In both cases, however, I’d argue that the
aesthetically preferable design, and the method least likely to introduce
errors, is the one that is most consistent with the rest of the language.
Things tend to be uglier when they stand out as unusual, and habits force
us to follow patterns, introducing errors when the pattern doesn’t hold.

From that perspective, this is what Swift looks like everywhere else:

if x = 3 { print(“Three”) }
else if x = 5 { print(“Five”) }
else { print(“Default”) }

It also doesn’t shy away from nested braces:

var x:Int {
get { return _x }
set { _x = newValue }
}

Aesthetically, is it less ugly to have some scopes require braces and
others not? I really thought the square bracket messaging syntax of Obj-C
was ugly until I got used to it because square brackets were for
subscripting and looked “heavy” for method calls.

From an ease of use perspective, it is more likely to forget to add a
closing brace when braces are used everywhere, or to accidentally add one
in the one place they aren’t?

―=What Isn’t Like C Shouldn’t Look Like C=―

There’s also the point that `switch` statements in Swift aren’t the same
as those in C. The different scoping rules are one difference. The lack of
default fall through is another. And of course the additional capabilities
of the `case` condition itself.

For those reasons, deviating from the C syntax might not only be
justified, but desirable as a notational reminder that this isn’t your
father’s `switch` statement. The closing brace in particular gives a
visual cue that fall through isn’t going to happen.

―=Leaving the Door Open for a `switch` Expression=―

Another commonly rejected proposal is the request for a `switch`
expression:
https://lists.swift.org/pipermail/swift-evolution/2015-December/000393.html

To my eyes, the rejection of this proposal is not as iron clad as the
rejection of removing curly braces. Here’s a quote from Chris Lattner:

"FWIW, I (and many other people) would like to consider turning many
statement-y things in swift into expressions. I’d love to see the weird ?:
ternary operator get nuked and replaced with an if/else expression of some
sort. This is an area that the apple team hasn’t had bandwidth to consider
carefully.

That said, there are challenges here in the details. How will the grammar
work?”

I think wrapping the `case` statements in curly braces in the statement
version of `switch` gets us closer to a reasonable answer for how the
grammar might work on an expression version: the expression version would
be delimited with colons similar to how the ternary operator is.

Something like this might work:

let s:String? = switch x
              case 3: “Three”
              case 5: “Five”
              default: nil

In the expression, the `case` clauses don’t represent scopes and shouldn’t
be curly braced so the colons give a nice syntactic distinction.

I’m not holding by breath for such a feature, but this change to the
`switch` statement makes such a thing easier to adopt.

On Jul 10, 2016, at 13:37 , Dennis De Mars <demars@fractaldomains.com> > wrote:

I don’t like this idea at all. The current switch syntax is really clean,
one of the nicest parts of Swift, and this would really turn it into
something messy.

I’ll make a possibly controversial statement here: one of the worst
aspects of C syntax, which is unfortunately perpetuated by many modern
languages, Swift included, is the use of curly braces everywhere to
demarcate every kind of block: every control structure, every data
structure and every function body.

This leads to a proliferation of nested braces which all have to be placed
correctly in order for the code to be correct. Of course, we all use
indentation to help manage this, but I think we all know that once the
closing brace is sufficiently far from the opening brace, it becomes
difficult to tell which brace matches which even with indentation. I think
I spend a significant amount of my development time just eyeballing those
closing braces. Of course, we also have editor features to help match them
up but relying on such editor features might be an indication of a flaw in
the language. At any rate, it impedes readability of the code, editor or no
editor.

Not having the braces for each case is, to me, analogous to the way Swift
removed the outermost parenthesis in the if statement conditional part.
When you have a complex conditional expression with nested parentheses,
removing that unnecessary outermost pair really improves readability (and
reduces possibility of error). This can be done because the outermost
parentheses aren’t really necessary to demarcate the boundaries of the
expression.

Similarly, the case keywords in the switch statement sufficiently
demarcate the extent of the statement block; it is unnecessary to toss in
an extra pair of these brace characters that may already be heavily used in
the statement block itself.

I think the extra burden on readability (and writability) of having the
extra pair of nested braces is not justified by the desire for consistency.
If consistency is so important, then rather than detracting from the
quality of the switch statement by adding the braces, why don’t we improve
the quality of the rest of the language by getting rid of some of those
braces in the other constructs that use them! (Note: I don’t really expect
that to happen…)

- Dennis D.

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

------------- End Message -------------

From James F
_______________________________________________
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

--
-Saagar Jha


(Chéyo Jiménez) #6

The issue I see is that diverging from the c-based switch needs to have a much better solution and I just don't think that swapping the colon for curly braces is that much better to motivate a move away from c-based languages. I would err on the side on familiarity.

···

On Jul 18, 2016, at 12:31 PM, Saagar Jha <saagarjha28@gmail.com> wrote:

Was the problem with the ternary conditional operator that nothing could be found to replace it? That doesn't seem to be the issue here.

On Mon, Jul 18, 2016 at 00:02 Jose Cheyo Jimenez via swift-evolution <swift-evolution@swift.org> wrote:
I think this proposal is not

""better enough" for it to make sense to diverge from the precedent established by the C family of languages.”

And I think the same would go for this

“Swift is designed to feel like a member of the C family of languages. Switching keywords away from C precedent without strong motivation is a non-goal”

https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

I just don’t think we gain much by switching to curly braces.

I made a similar argument about getting rid of the elvis operator ( ?: ) because it used colons and question marks.

On Jul 17, 2016, at 2:27 PM, G B via swift-evolution <swift-evolution@swift.org> wrote:

I think the discussion on this has run its course and it sounds like there’s mixed feelings, but it’s mostly a matter of opinion between consistency and “ugliness”. As I understand it, the “socialization” process isn’t meant to reach consensus, but to hone the proposal (or abandon it if the feedback is overwhelmingly negative). I think my last formulation is probably as well formed as I’ll get with the idea, I think there’s still mixed feedback, and a review is the way to settle the differences of opinion.

I think a proposal like this is in scope for Swift 3, and this is probably the last reasonable opportunity to consider it for a while, is that correct?

If so, I’ll put together a formal proposal.

The general process is described here:
https://github.com/apple/swift-evolution/blob/master/process.md
but I just want to double check the process because I’m not terribly familiar with GitHub, pull requests, etc and want to avoid generating more noise than I need to:

I need to clone the swift-evolution repo
Create a local branch
Copy the proposal template, and edit it for the proposal
Push the branch (do I need special permissions for this, or can anyone push a branch?)
Flag the branch for a pull request

Presumably someone else along the line assigns it a number.

Anything else I need to consider?

On Jul 11, 2016, at 02:04 , James Froggatt via swift-evolution <swift-evolution@swift.org> wrote:

While I'm not keen on introducing braces, your comparison to property getters and setters is a good one. This is an inconsistency.

To be honest, I wouldn't mind putting up with braces for a while, with the promise that we'll get a lightweight alternative to the switch statement, like the ternary operator is to if statements.
I feel like I use switch much more often to initialise a variable, or return a value, than I do to branch program logic (especially working with with enums), and it already seems a very heavy construct in these cases.

------------ Begin Message ------------
Group: gmane.comp.lang.swift.evolution
MsgID: <0C3EC993-9320-4F4C-B2AA-66967BEDFFED@gmail.com>

The discussion so far has given me a chance to organize my thinking, so here’s a more complete train of thought.

I get that people don’t like extra punctuation. The commonly rejected proposals, however, make it clear that braces are here to stay and we should be designing the syntax right now with that in mind. It took me a long time to get used to not using them in Python, now I’m getting used to using them again in Swift. Swift has a long life ahead of it, and there are going to be plenty of places where the syntax is going to become inconsistent in the service of supporting new features. Now is when we set the starting point though and try to set ourselves up in a way that requires a minimum of syntax goofs in the future.

―=Philosophy=―

As philosophical backdrop, here’s the link on removing braces in the “commonly rejected proposals” section:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003656.html

I’ll pull out two quotes from that post, one from Kevin Ballard:
"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 another edited as suggested by Chris Lattner:
"'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 is most familiar to programmers in the extended C family is a good idea."

So, from that I take:
1) braces indicate scoping
2) conciseness isn’t an end in itself
3) we should err on the side of being Cish when no other arguments prevail.

―=In C `cases` Aren’t Scopes, in Swift They Are=―

Starting from what’s Cish, here’s a snippet of Swift code:

let x=5
switch x {
case 3:
  let y=5
  print(x," ",y)

case 5:
  print("Two",x,"s”)

default:
  print(“default")
}

This runs fine and prints “Two 5 s” to the console.

This is something similar in C:

int x=5;
switch (x) {
case 3:
  int y=5;
  printf("%d %d",x,y);
  break;

case 5:
  printf("Two %d s",x);
  break;

default:
  printf(“default");
}

This code fails. C gives me an error pointing at `int y=5;` complaining that it expected an expression there. C++ gives me an error that it can’t jump to `case 5:` because it would skip over the declaration of `y`.

I can fix this in both C and C++ by wrapping the `case 3:` in curly braces, creating a local scope:

int x=5;
switch (x) {
case 3: {
  int y=5;
  printf("%d %d",x,y);
  break;
}

case 5:
  printf("Two %d s",x);
  break;

default:
  printf("default");
}

This code compiles fine in both C and C++. A new scope has been delimited and created, and `y` only exists in that scope.

So, by both criteria 1) and 3), Swift should be using braces on `case` statements. Each case is a scope unto itself, and the extended C family of languages would require braces in that event.

―=Conciseness, Ugliness and Nested Braces=―

Conciseness is not an emphasis of Swift, but even if it were then this is not a particularly in-concise change to the syntax. The suggestion here is to remove one punctuation mark and add two for a net gain of 1 character. This doesn’t strike me as unduly burdensome.

The better arguments are those on aesthetics and ease of use. Each of these seems to focus on opposite situations. The ugliness is when there is only one line per case, the ease of use challenge is when there are many and the developer needs to determine how many braces to close.

How common is it to have a single line per case?

Aesthetics, at least, are mostly subjective. Ease of use, in part, depends on habits. In both cases, however, I’d argue that the aesthetically preferable design, and the method least likely to introduce errors, is the one that is most consistent with the rest of the language. Things tend to be uglier when they stand out as unusual, and habits force us to follow patterns, introducing errors when the pattern doesn’t hold.

From that perspective, this is what Swift looks like everywhere else:

if x = 3 { print(“Three”) }
else if x = 5 { print(“Five”) }
else { print(“Default”) }

It also doesn’t shy away from nested braces:

var x:Int {
get { return _x }
set { _x = newValue }
}

Aesthetically, is it less ugly to have some scopes require braces and others not? I really thought the square bracket messaging syntax of Obj-C was ugly until I got used to it because square brackets were for subscripting and looked “heavy” for method calls.

From an ease of use perspective, it is more likely to forget to add a closing brace when braces are used everywhere, or to accidentally add one in the one place they aren’t?

―=What Isn’t Like C Shouldn’t Look Like C=―

There’s also the point that `switch` statements in Swift aren’t the same as those in C. The different scoping rules are one difference. The lack of default fall through is another. And of course the additional capabilities of the `case` condition itself.

For those reasons, deviating from the C syntax might not only be justified, but desirable as a notational reminder that this isn’t your father’s `switch` statement. The closing brace in particular gives a visual cue that fall through isn’t going to happen.

―=Leaving the Door Open for a `switch` Expression=―

Another commonly rejected proposal is the request for a `switch` expression:
https://lists.swift.org/pipermail/swift-evolution/2015-December/000393.html

To my eyes, the rejection of this proposal is not as iron clad as the rejection of removing curly braces. Here’s a quote from Chris Lattner:

"FWIW, I (and many other people) would like to consider turning many statement-y things in swift into expressions. I’d love to see the weird ?: ternary operator get nuked and replaced with an if/else expression of some sort. This is an area that the apple team hasn’t had bandwidth to consider carefully.

That said, there are challenges here in the details. How will the grammar work?”

I think wrapping the `case` statements in curly braces in the statement version of `switch` gets us closer to a reasonable answer for how the grammar might work on an expression version: the expression version would be delimited with colons similar to how the ternary operator is.

Something like this might work:

let s:String? = switch x
              case 3: “Three”
              case 5: “Five”
              default: nil

In the expression, the `case` clauses don’t represent scopes and shouldn’t be curly braced so the colons give a nice syntactic distinction.

I’m not holding by breath for such a feature, but this change to the `switch` statement makes such a thing easier to adopt.

On Jul 10, 2016, at 13:37 , Dennis De Mars <demars@fractaldomains.com> wrote:

I don’t like this idea at all. The current switch syntax is really clean, one of the nicest parts of Swift, and this would really turn it into something messy.

I’ll make a possibly controversial statement here: one of the worst aspects of C syntax, which is unfortunately perpetuated by many modern languages, Swift included, is the use of curly braces everywhere to demarcate every kind of block: every control structure, every data structure and every function body.

This leads to a proliferation of nested braces which all have to be placed correctly in order for the code to be correct. Of course, we all use indentation to help manage this, but I think we all know that once the closing brace is sufficiently far from the opening brace, it becomes difficult to tell which brace matches which even with indentation. I think I spend a significant amount of my development time just eyeballing those closing braces. Of course, we also have editor features to help match them up but relying on such editor features might be an indication of a flaw in the language. At any rate, it impedes readability of the code, editor or no editor.

Not having the braces for each case is, to me, analogous to the way Swift removed the outermost parenthesis in the if statement conditional part. When you have a complex conditional expression with nested parentheses, removing that unnecessary outermost pair really improves readability (and reduces possibility of error). This can be done because the outermost parentheses aren’t really necessary to demarcate the boundaries of the expression.

Similarly, the case keywords in the switch statement sufficiently demarcate the extent of the statement block; it is unnecessary to toss in an extra pair of these brace characters that may already be heavily used in the statement block itself.

I think the extra burden on readability (and writability) of having the extra pair of nested braces is not justified by the desire for consistency. If consistency is so important, then rather than detracting from the quality of the switch statement by adding the braces, why don’t we improve the quality of the rest of the language by getting rid of some of those braces in the other constructs that use them! (Note: I don’t really expect that to happen…)

- Dennis D.

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

------------- End Message -------------

From James F
_______________________________________________
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

--
-Saagar Jha


(G B) #7

The main advantage is not in this change by itself, but in the fact that it tidies up the syntax and makes it easier to support other additive proposals in the future that might make better use of the colon syntax— such as targeted continue statements in `switch` or a `switch` expression syntax. Both could probably be accomplished without this change, but I think they’d be less clean.

I guess my argument on familiarity has been that using curly braces is more like the C family of languages in that the Swift `case`s are separate scopes and C/C++ would require curly braces to create those scopes. At the same time the Swift `switch` is different from the C `switch` in that it does not implicitly fall through so a small syntax difference isn’t without justification.

That said, reactions haven't been overwhelmingly positive, so I’ll let it go unless someone suggests otherwise.

···

On Jul 18, 2016, at 16:23 , Chris Lattner <clattner@apple.com> wrote:

On Jul 17, 2016, at 10:07 PM, Jose Cheyo Jimenez via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I think this proposal is not

""better enough" for it to make sense to diverge from the precedent established by the C family of languages.”

And I think the same would go for this

“Swift is designed to feel like a member of the C family of languages. Switching keywords away from C precedent without strong motivation is a non-goal”

https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

I just don’t think we gain much by switching to curly braces.

I agree. I don’t think this proposal is worth considering at this point.

-Chris


(Jaden Geller) #8

I also agree that curly braces would be both *more* clear and *more* C-like for what it’s worth, but it seems like there may be no time for this. :disappointed:

···

On Jul 19, 2016, at 5:01 PM, G B via swift-evolution <swift-evolution@swift.org> wrote:

The main advantage is not in this change by itself, but in the fact that it tidies up the syntax and makes it easier to support other additive proposals in the future that might make better use of the colon syntax— such as targeted continue statements in `switch` or a `switch` expression syntax. Both could probably be accomplished without this change, but I think they’d be less clean.

I guess my argument on familiarity has been that using curly braces is more like the C family of languages in that the Swift `case`s are separate scopes and C/C++ would require curly braces to create those scopes. At the same time the Swift `switch` is different from the C `switch` in that it does not implicitly fall through so a small syntax difference isn’t without justification.

That said, reactions haven't been overwhelmingly positive, so I’ll let it go unless someone suggests otherwise.

On Jul 18, 2016, at 16:23 , Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

On Jul 17, 2016, at 10:07 PM, Jose Cheyo Jimenez via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I think this proposal is not

""better enough" for it to make sense to diverge from the precedent established by the C family of languages.”

And I think the same would go for this

“Swift is designed to feel like a member of the C family of languages. Switching keywords away from C precedent without strong motivation is a non-goal”

https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

I just don’t think we gain much by switching to curly braces.

I agree. I don’t think this proposal is worth considering at this point.

-Chris

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


(Jaden Geller) #9

It’s probably worth pointing out that Swift's `switch` statement has been a thing I’ve seen new programmers struggle with when learning Swift. The syntax differs quite significantly from other control flow constructs in the language.

···

On Jul 19, 2016, at 5:04 PM, Jaden Geller <jaden.geller@gmail.com> wrote:

I also agree that curly braces would be both *more* clear and *more* C-like for what it’s worth, but it seems like there may be no time for this. :disappointed:

On Jul 19, 2016, at 5:01 PM, G B via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

The main advantage is not in this change by itself, but in the fact that it tidies up the syntax and makes it easier to support other additive proposals in the future that might make better use of the colon syntax— such as targeted continue statements in `switch` or a `switch` expression syntax. Both could probably be accomplished without this change, but I think they’d be less clean.

I guess my argument on familiarity has been that using curly braces is more like the C family of languages in that the Swift `case`s are separate scopes and C/C++ would require curly braces to create those scopes. At the same time the Swift `switch` is different from the C `switch` in that it does not implicitly fall through so a small syntax difference isn’t without justification.

That said, reactions haven't been overwhelmingly positive, so I’ll let it go unless someone suggests otherwise.

On Jul 18, 2016, at 16:23 , Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

On Jul 17, 2016, at 10:07 PM, Jose Cheyo Jimenez via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I think this proposal is not

""better enough" for it to make sense to diverge from the precedent established by the C family of languages.”

And I think the same would go for this

“Swift is designed to feel like a member of the C family of languages. Switching keywords away from C precedent without strong motivation is a non-goal”

https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

I just don’t think we gain much by switching to curly braces.

I agree. I don’t think this proposal is worth considering at this point.

-Chris

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