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
