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

[Thorsten Seitz]

> Am 01.06.2016 um 00:26 schrieb Paul Cantrell via swift-evolution <swift-evolution at swift.org>:
> 
> 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)
>     }

I don't think that is so confusing. Much more confusing is that the let binding within the `if` statement is conditional!
So, in essence we are already looking at very different clauses and I'd actually prefer if the conditional let binding would require explicit `let` for each binding just to emphasize that a conditional let binding is happening!
To fix any confusion between these I'd rather change the syntax of the conditional let binding to something like `let x ?= x` or similar (which has been proposed quite a few times on this list already).
Worsening the syntax of conditionals instead is no option IMHO.

-Thorsten 



> 
> 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 <hooman at 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 at 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 at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> 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/20160601/0926ad00/attachment.html>