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

Wed Jun 1 12:09:10 CDT 2016

 > 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).

FWIW, I also think `if let one = two` is not descriptive enough about what 
is going here.. `if let one ?= two` or even `if let one = two!` will be 
more clear for me : we are trying to unwrap and assign.

On 01.06.2016 19:46, Thorsten Seitz via swift-evolution wrote:
>
>
> Am 01.06.2016 um 00:26 schrieb Paul Cantrell via swift-evolution
> <swift-evolution at swift.org <mailto: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
>>> <mailto: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 <mailto: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 <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto: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
>