[swift-evolution] [Idea] Wrap switch cases in curly braces
G B
g.c.b.at.work at gmail.com
Sun Jul 17 16:27:51 CDT 2016
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 at 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 at 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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ------------- End Message -------------
>
>
>
> From James F
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
More information about the swift-evolution
mailing list