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

[Paul Cantrell]

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