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 <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 > <[email protected]> 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 >> <[email protected]> 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: <[email protected]> >> >> 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 <[email protected]> >>> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> ------------- End Message ------------- >> >> >> >> From James F >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
