# Obsoleting \`if let\` **URL:** \ **Category:** Discussion\ **Created:** [February 3, 2016, 11:36pm UTC](https://forums.swift.org/t/obsoleting-if-let/1301 "2016-02-03T23:36:47Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![Chris\_Lattner](https://avatars.discourse-cdn.com/v4/letter/c/bc8723/32.png) [@Chris\_Lattner](https://forums.swift.org/u/Chris_Lattner)\ **Post date:** [February 4, 2016, 12:25am UTC](https://forums.swift.org/t/obsoleting-if-let/1301/4 "2016-02-04T00:25:15Z")
> Data point (which Chris brought up already, I think?): We tried this\* and got a lot of negative feedback. Optionals are unwrapped too often for people to be comfortable writing "if let name? = optionalCondition”. Yes, I even implemented this and it was in the compiler for awhile, then later ripped it back out. You can find the history in git. I would guess that this all happened in ~March 2015. -Chris > **···** > > > On Feb 3, 2016, at 3:47 PM, Jordan Rose via swift-evolution \ wrote: > > > It may be more uniform and even more pedantically correct, but our users hated it. > > > > Jordan > > > > \* The actual thing we tried only allowed patterns that began with 'let', but that's close enough. > > > > > On Feb 3, 2016, at 15:36, Brent Royal-Gordon via swift-evolution \\> wrote: > > > > > > 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 > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org \ > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) --- _[View the full topic](https://forums.swift.org/t/obsoleting-if-let/1301)._