> Am 01.06.2016 um 00:26 schrieb Paul Cantrell via swift-evolution
> <[email protected]>:
>
> 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 <[email protected]> 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
>>> <[email protected]> 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
>>> [email protected]
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
