`if let` shorthand

[Jumhyn (Frederick Kellison-Linn)]

My thoughts on this remain similar to what I had to say last May:

@Jumhyn

Overall, if let x { ... } feels like a good (new) balance of brevity and clarity. It maintains the existing ' if let ' phraseology that I expect most Swift programmers have come to instinctively understand as "bind if non-optional," and the additional behavior is (IMO) easily explainable. It feels so natural to me that I semi-frequently find myself writing it and getting a syntax error before remembering that it's not already supported!

Since I haven't seen it otherwise mentioned in this thread, I'll also resurface what I think is important precedent in the language for having special language support for the "initialize a new binding that shadows an existing binding with the same name". We already allow this for closure capture lists:

@Jumhyn

As for "omit[ting] the action," we already have another place where we allow a variable name on its own to be expanded to an initialization of a new variable with the same name:

let closure = { [x] in // implicitly: 'let x = x'
    ...
}

This works even if x refers to e.g., self.x in the outer scope.

So we aren't inventing an entirely new concept here.

As for if let x { vs. if let x? {: as noted above, I think if let already serves as a pretty strong indicator to Swift programmers that there's an optional unwrap happening, but the signal may not be as strong for, say, if var (or future if inout, if ref) unwrapping shorthand. So perhaps that's a case for requiring the trailing question mark, though also maybe those uses won't be common enough to justify 'muddying' the overwhelmingly common if let case. I think I have a weak preference for if let x? but could very likely be happy with either in the language.