> On May 27, 2016, at 3:06 PM, Brandon Knope via swift-evolution
> <swift-evolution@swift.org> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
