I was using the word that the proposal author even used! Couldn't the same be said for the comma though?
Sent from my iPad > On May 27, 2016, at 10:48 PM, Jacob Bandes-Storch <[email protected]> wrote: > > I haven't had time to carefully read this whole thread, but I don't think I > agree that this syntax is "uglier". > > Isn't it true that semicolons are used regularly in English; that they > delimit separate clauses, boolean or otherwise; and that the proposed syntax > mirrors English grammar pretty well (perhaps depending on which manual of > style you choose)? > > Jacob > >> On Fri, May 27, 2016 at 7:28 PM, Brandon Knope via swift-evolution >> <[email protected]> wrote: >> As a *user* of the language, I find it a little disconcerting that we would >> make the syntax uglier just to serve the grammar. Where is the benefit to >> the user with this? Especially at the cost of making it slightly uglier? >> >> And sorry, but what is a boolean assertion? :embarrassed face: >> >> Brandon >> >> Sent from my iPad >> >>> On May 27, 2016, at 8:13 PM, Erica Sadun <[email protected]> wrote: >>> >>> >>>> On May 27, 2016, at 3:06 PM, Brandon Knope via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> Second, I have really gotten use to not needing to use semicolons, and >>>> this proposal seems to use/require them in very common situations. >>>> >>>> After shedding the requirement of semicolons from ObjC…now we will have to >>>> use them a lot again? >>>> >>>> >>>> Third, the format will look like this in most people’s code: >>>> guard x == 0; let y = optional; y == 2 else { //can the third bool >>>> condition even refer to y? Is it still in scope? >>>> ... >>>> } >>>> (in the above example, y == 2 is related to the optional that precedes it. >>>> Now it looks like a distinct statement) >>>> >>>> compared to >>>> >>>> guard x == 0, let y = someOptional where y == 2 else { >>>> ... >>>> } >>>> >>>> >>>> To my eyes: the old way reads more naturally and looks less heavy. I think >>>> it keeps its expressiveness and also keeps it somewhat poetic. >>> >>> This proposal serves the grammar, enabling it to simplify, the compiler to >>> avoid errors, and the developer to intermingle tests more naturally, as you >>> would in processing JSON without having to nest or sequence separate guard >>> statements. A main goal is differentiating the commas between conditions >>> and in binding conditions, as you ask about below >>> >>> I don't think it's practical to use a second braced scope: >>> >>> guard { >>> condition >>> condition >>> condition >>> } else { >>> leave scope >>> } >>> >>> This would be confusing to anyone doing conditional binding for use in the >>> top level scope; the bindings would "escape" the braces. Using semicolons >>> establishes a balance between separating different kinds of conditions and >>> allowing comma-delineated multiple bindings. >>> >>> Current state: >>> >>> * Confusing, complicated, organically grown grammar >>> * Inability to use independently standing Boolean assertions after the >>> first (except for one outlier availability case) >>> >>> Proposed state: >>> >>> * Very simple grammar >>> * Developer-directed ordering of binding, availability, Boolean assertions, >>> cases, used in the order they're consumed >>> * Slightly uglier >>> >>> The cost for this is a separator between conditions >>> >>>> Also, can someone refer me to an example of this statement: "This proposal >>>> resolves this problem by retaining commas as separators within clauses (as >>>> used elsewhere in Swift) and introducing semicolons to separate distinct >>>> kinds of clauses (which aligns with the rest of the Swift language)” >>> >>> guard let x = opt1, y = opt2, z = opt3; booleanAssertion else { } >>> >>>> >>>> I rarely see any semicolons after the removal of C loops. So if someone >>>> could put me to where this is used elsewhere in Swift, please do! >>> >>> Using semicolons brings conditions in-line with how semicolons are used as >>> separators elsewhere in the Swift grammar. >>> >>> -- Erica >>> >>> >> >> _______________________________________________ >> 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
