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 <[email protected]> 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 >> <[email protected]> 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 >>> <[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 > > -- > -Saagar Jha
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
