> 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@swift.org <mailto:swift-evolution@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 <hoo...@mac.com
<mailto: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 <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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
