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
