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 <[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] <mailto:[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] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
