[swift-evolution] Obsoleting `if let`

Brent Royal-Gordon brent at architechies.com
Wed Feb 3 17:36:47 CST 2016


This is a continuation of and alternative proposal to "The bind thread", which seems to have petered out without consensus.

Currently there are three forms of `if` statement (and `guard` and `while`, but for simplicity I'll just say `if` throughout this discussion):

	if booleanCondition
	if let name = optionalCondition
	if case pattern = expression

The boolean condition form is fine, but there are flaws in the other two. `if let` is unprincipled and doesn't really say what it does; `if case` is bulky and rarely used.* 

One very interesting thing about `if case`, too, is that it can actually do optional unwrapping:

	if case let name? = optionalCondition

This avoids the problems with `if let`—it's principled (it comes from a larger language feature) and it explicitly says it's handling optionality—but it still runs up against `if case`'s rarity and wordiness.

So what I suggest is that we drop the `if let` form entirely and then drop the `case` keyword from `if case`. Pattern-matching conditions can still be distinguished from boolean conditions because boolean conditions can't contain an `=` operator. This, there would now only be two forms of if:

	if booleanCondition
	if pattern = expression

And the current `if let` is handled elegantly and clearly by existing pattern-matching shorthand, with only one additional character needed:

	if let name? = optionalCondition

I see two complications with this.

The first is that, naively, `if let foo = bar` would still be valid, but would have different and vacuous behavior, since the pattern cannot fail to match. The compiler should probably emit an error or at least a warning when this happens.

The second is our other weird use of the `case` keyword, `for case`, which is now an orphan in the language. I see several ways this could be handled:

1. Drop the `for case` functionality entirely; if you want that behavior, use a pattern-matching `if`.
2. Replace the loop variable slot in the `for` statement with a pattern. This would force you to put `let` on all simple `for` statements.
3. Try to automatically distinguish between simple variables/tuples and patterns in this slot. What could possibly go wrong?
4. Require an equals sign before the `in`, like `for let foo? = in optionalFoos`. Looks a little gross, but it's unambiguous.
5. Replace `for case` with `for if`, like `for if let foo? in optionalFoos`. This helps flag the unusual conditional behavior of this form of `for`.
6. Just keep `for case` and don't worry about the fact that it's not parallel to the other statements anymore.

Thoughts on any of this?



* `if case` also has the problem that the `=` isn't appropriate unless you happen to bind some of the data matched by the pattern, but I don't know how to address that. A prior version of this proposal suggested saying `:=` instead of `=`, with the idea that `:=` could become a general pattern-matching operator, but the people I talked over this post with hated that.

-- 
Brent Royal-Gordon
Architechies



More information about the swift-evolution mailing list