Exactly what I feel about this.
I am prepared to go as far as disallowing:
let x = optionalX, y = optionalY
syntax to free up comma for use instead of semicolon. Then the above becomes:
let x = optionalX, let y = optionalY
In this case we will keep the comma at the end of the line as well.
> On May 31, 2016, at 2:25 PM, Paul Cantrell via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Returning to the list after a brutally busy spring, a demi-review:
>
> I vote…
>
> +1 on addressing this problem,
> +1 on the proposal’s structural approach (list of items which may be either
> boolean tests or bindings, in any order), and
> +1 on eliminating “where” in the presence of a better approach,
>
> …but am ambivalent about the semicolon. Hereafter follows a slushy reflection
> on my deepest inner thoughts and feelings about syntax.
>
> The logic behind the semicolon makes perfect sense, but my initial gut
> reaction agrees with others who say it just isn’t pleasant to read. I spent
> some time fiddling with places in my code where I’ve used “if … where” and
> tried the proposed syntax instead. It feels … off.
>
> Commas in the same spots feel better somehow. I spent some time reflecting on
> why this might be, and I think it’s just that my brain is so strongly trained
> to parse the semicolon as a statement separator. IOW, my mental hierarchy is
> this:
>
> expression
> comma
> statement
> semicolon ←
>
> …(and this is intuitively true for me despite the C-style for loop), but the
> proposal asks us to read this way instead:
>
> expression
> comma
> semicolon ←
> statement
>
> In particular, my years of C trained me to spot this mistake:
>
> if(foo < bar);
> oopsThisAlwaysExecutes();
>
> …and seeing that semicolon on the same line as the “if” in Swift triggers
> that deeply conditioned alarm bell. Then again, “if let” and “if case” have
> always felt weirdly wrong to me as well, and I eventually got used to them.
> I’d probably get used to this proposed syntax as well.
>
> The line breaks look better than semicolons, but suffer a bit from the same
> “statement boundary” brain retraining problem.
>
> Somebody proposed && (Brent maybe?). I tried it out too. It’s surprisingly
> pleasant to read, but makes it look like I should be able to arbitrarily
> embed bindings deep in expressions in ways that would open hideous cans of
> worms:
>
> if let foo = bar && barTest(foo) || let foo = baz && bazTest(foo) {
> // Is foo defined here? What is its type? Yikes!
> }
>
> Communicating that the top-level separator in a condition clause is not just
> another boolean operator does seem important.
>
> Bottom line: the proposal addresses a real problem, and the proposed solution
> is an improvement. If the choice is either current syntax or SE-0099, I vote
> for SE-0099. I have a nagging feeling there’s a better third choice out there
> somewhere. If there isn’t, then I’ll take SE-0099.
>
> Cheers,
>
> Paul
>
>
> _______________________________________________
> 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
