[swift-evolution] [Review] SE-0099: Restructuring Condition Clauses

[Jacob Bandes-Storch]

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 <
swift-evolution at swift.org> 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 <erica at ericasadun.com> wrote:
>
>
> On May 27, 2016, at 3:06 PM, Brandon Knope via swift-evolution <
> swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160527/68b173a4/attachment.html>