I certainly am warm to that myself, although I’m also sympathetic to what Chris wrote about the inconsistency it introduces:
let x = optionalX!, y = optionalY! // Works! doStuff(x, y) if let x = optionalX, y = optionalY { // Doesn’t work. Confusion! doStuff(x, y) } Also, eliminating the repeated “let” in a big list of conditional bindings is a common practice: if let firstName = json["first_name"], lastName = json["last_name"], street = json["street"], state = json["state"], zip = json["zip_code"] { ... } …and some style guides even go out of their way to recommend this over the repeated “let.” Popular feature, so I’d be hesitant to nix it. P > On May 31, 2016, at 5:04 PM, Hooman Mehr <hoo...@mac.com> wrote: > > 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 <mailto: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 <mailto: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