Sent from my iPad
> On May 27, 2016, at 7:13 PM, Erica Sadun via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>> 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
But we don't *have* to pay that cost if we handle them the same as other
semicolons in the language.
>
>> 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.
Not really. We can use a newline instead of the semicolon elsewhere.
>
> -- Erica
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
