Let's fix `if let` syntax

[Avi]

@ConfusedVorlon

(not least alt+click on the function which currently shows the definition)

Not for definitions for which there is no code.

[DeFrenZ (Davide De Franceschi)]

This is something that I'd like to see improve, because it's such a pervasive pattern that deserves some sugar (as mentioned by @Ben_Cohen), but for the same reason a lot of things depend on it. A few points that are imho important:

• I think that it's relevant to leave the assignment explicit, because it does imply different behaviours (see the examples from @jrose), so I would keep let and = in the expression
• This should work for both let and var
• This should work for if, guard and for
• Ideally this doesn't over-focus on Optional but keeps an eye at other kinds of "unwrappings" (like monadical wrappers)
• It's resilient to renames, so the assigned value name shouldn't appear twice (this could be partially solved by tooling as mentioned by @mayoff)
• Autocomplete can work (if it actually does would depend on the tooling), so there needs to be some symbols between the let and the symbol to be able to understand that there should be a scope symbol in there

The suggestion that seems to work with these is if let '' = myOptionalVar (or any other symbol instead of '' for "ditto", like unwrap). The issue with it is that there's "one more thing" to learn still...

[ConfusedVorlon]

@Avi

@ConfusedVorlon

(not least alt+click on the function which currently shows the definition)

Not for definitions for which there is no code.

yes - I guess it gets ugly when you're essentially providing info on calling sites within functions.
I think you can get round that by moving the annotation up to the function definition though
(so that it can be exposed via the header)

func run(_ callback:(result:MyResult, data:Data, error:Error)->Void {
  self.callback = callback
//do networking stuff
} 

this is looking kinda familiar now - was it the case that blocks once did have the option of naming variables???

[hisekaldma (Jonathan Hise Kaldma)]

@jawbroken

That it doesn't naturally work to unwrap other.thing is a feature to me, because you should probably think about giving other.thing a different name in this scope (e.g. otherThing , specificThing ), as opposed to if let x where x should already be a name that makes contextual sense.

FWIW, when it’s just a simple property access, in our codebase it’s mostly if let thing = other.thing and not if let otherThing = other.thing. I think the reason is that often there’s only a single other you’re doing something with, so the context is clear enough. The unwrappings that get more descriptive names are the ones where there is a longer optional chain or function call involved. But even then, sometimes it’s just if let thing = other.third?.thing.

[jawbroken]

I don't know how universal that is and I don't like that mentioning one name (e.g. other.thing) creates a variable with a completely different name (e.g. thing). I wouldn't like var other.thing to mean var thing = other.thing either. You're at the point of diminishing returns when you're just avoiding repeating a part of the name.

if let x has an easily teachable explanation as a shorthand syntax for if let x = x, similar to the explanation of the various shorthands for closures, and I don't personally have an desire to make it more complicated than that.

[Chris_Lattner3 (Chris Lattner)]

@Ben_Cohen

My feeling is the opposite. An additional word seems clunky to me. Why introduce a new word when ? is already used for the very similar case let x?: in switches – a use case that's less common in day-to-day code than the one we're talking about here but definitely benefits from a delightfully lightweight syntax.

Because using it here would be overloading it in a new and different way. This erodes and dilutes the existing meaning of ? in patterns by addition a different meaning in a very similar syntactic construct. I think such a move would make the language more confusing and would make patterns more difficult to explain. Since there is no obvious reason we need to do that, I recommend we pick a different form. This is really the crux of why the discussion went no where in the past.

I'm not arguing for unwrap specifically, I'm arguing that we use a new explicit form to represent this new concept. I'm not sure I agree with your argument against unwrap though: it isn't onerous to require a short word over a sigil. The whole point of the sugar argument is the DRY thing, which is still accomplished.

-Chris

[Chris_Lattner3 (Chris Lattner)]

@jawbroken

I don't understand why everyone is trying to invent a different spelling here when if let x is seemingly unambiguous and so obvious to Swift developers that it has been repeatedly proposed/discussed in that form over the 6+ years I've been reading the Swift forums/mailing lists. If it's not going to be if let x then I'm going to struggle to support it.

if let x { is better than if let x? {, but omits the action from what is happening here. This is obvious if you memorize it, but doesn't help new programmers.

The problem with it is that it begs the question about "can I do if var x {. What is your opinion?

-Chris

[jawbroken]

if let x = x already omits the action of unwrapping so I'm not personally concerned about also omitting the explicit copy here. It seems very teachable, in the same way that shorthand closure syntax is currently taught by showing equivalent forms and sequentially omitting parts. I actually didn't know that you could already write if var x = x to unwrap, I've only ever used the let form, but given that is allowed then I don't see the harm in allowing if var x also.

[Jumhyn (Frederick Kellison-Linn)]

I broadly agree with others in the thread saying that if let x { ... } feels like the most 'natural' spelling for this shorthand. I think the let or var introducer is important for communicating that there's a new binding occurring, compared to e.g., the if x? { ... } alternative (and yes, I think var should be supported).

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.

In this case we don't even force (or permit) the user to specify let to indicate that there's a new binding occurring. However, I've found the lack of an introducer to be a hinderance for users trying to understand what's really going on in a capture list, and IMO it would be even worse of conditional binding since there's really two things going on at once—checking for nil, and binding a new name.

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!

[Avi]

I missed that on the first reading. I deleted my comment.

[jordanekay (Jordan Kay)]

@Ben_Cohen

I agree this is something worth addressing. if let x = x { } is so incredibly common that it clearly deserves some form of privileged syntax.

if let x = x { } already has some form of privileged syntax: x.map { }.

Optional.map is even defined in the documentation as an alternative to if let, without even referencing the closure’s return value at all:

Evaluates the given closure when this Optional instance is not nil , passing the unwrapped value as a parameter.

[David_Catmull]

@jordanekay

if let x = x { } already has some form of privileged syntax: x.map { } .

That doesn't help with guard let, though.

[Nevin]

@David_Catmull

That doesn't help with guard let , though.

A bit off-topic, but I was just trying out guard let x = x and found that it compiles in some scenarios but not others:

// At global scope

// Compiles

let x: Int? = 1

guard let x = x else {
  fatalError()
}

// Not at global scope

// Error: definition conflicts with previous value

do {
  let x: Int? = 1
  
  guard let x = x else {
    fatalError()
  }
}

// In a different scope from the original x

// Compiles

do {
  let x: Int? = 1
  
  do {
    guard let x = x else {
      fatalError()
    }
  }
}

(All tested in a playground with Xcode 11.3.1)

• • •

Edit: global scope allows weird things…

// This compiles and runs just fine:

let x: String? = "abc"

print(type(of: x))    // Optional<String>

guard let x = x?.count else {
  fatalError()
}

print(type(of: x))    // Int

But this does not compile:

let x: String? = "abc"
let x = x!.count
// Error: Variable used within its own initial value

And neither does this:

let x: String? = "abc"
let x = 3
// Error: Invalid redeclaration of 'x'

[BigSur ({ @MainActor  in M1.Ultra }(Swift))]

They all compile successfully in Xcode 12.5

@Nevin

let x: String? = "abc"
let x = x!.count

got //Error: Circular reference,
but it makes sense.

[schutt (Luke Schutt)]

Because I regularly use guard clauses to exit early, using var instead of let about 8% of the time, I think any change should handle var and let in both guard and if statements. It would be unfortunate if any syntactic sugar only handled one of these four cases.

[Nevin]

@BigSur

They all compile successfully in Xcode 12.5

Are you saying that this compiles in 12.5?

let x: String? = "abc"
let x = 3

What about this?

do {
  let x: String? = "abc"
  let x = 3
}

And this?

do {
  let x: String? = "abc"
  guard let x = x?.count else { fatalError() }
}

And, for completeness, this?

do {
  let x: String? = "abc"
  guard let x = Optional(3) else { fatalError() }
}

[BigSur ({ @MainActor  in M1.Ultra }(Swift))]

last two examples failed, but they should be failed.

@Nevin

do {
  let x: Int? = 1
  
  guard let x = x else {
    fatalError()
  }
}

I tested it in do{} and func block level, all compile succeed.

What is your " Not at global scope"?

[BigSur ({ @MainActor  in M1.Ultra }(Swift))]

@jordanekay

x.map { } .

Hmm... if Optional.map support else closure action, then x.map {} else:{...} should be the option.

[jordanekay (Jordan Kay)]

You can use ?? for the else case. x.map { doThing(x: $0) } ?? doOtherThing().

[Ben_Cohen]

@jordanekay

if let x = x { } already has some form of privileged syntax: x.map { } .

I'm all in favor of people using map when it's appropriate, but it is not the same. map is for mapping – an expression transforming the wrapped value inside an optional – not general purpose code using the wrapped value.

It also doesn't solve the issue at hand. Even if you were willing to use it (IMO inappropriately) as a general-purpose alternative to if let, then x.map { } is equivalent to if let $0 = x { }, which is exactly the kind of shorthand variable @chockenberry is saying is bad but the status quo encourages. Alternatively, if you think you should name the closure arguments, then you would need x.map { x in } which lands us back at square one.

(Also, by "privileged" I am speaking about adding custom handling into the language – in this sense Optional.map isn't really privileged because while it exists in the standard library, the same function can be written outside the std lib just as easily)