[Pitch] Nested if let and guard let

[bzamayo (Benjamin Mayo)]

I'm mixed on this idea. But regardless, the if let x { sugar is still so new, I feel like we should wait more time to observe how it is used before extending it further.

[Jon_Shier]

The name conflict seems fairly easily dealt with by a compiler error, same as if you'd manually tried to use duplicate names. I don't think that's a blocker for the pitch any more than the fact that if let one, let one = other.one leads to a conflict.

To me this seems like a fairly natural and minor addition to the existing shorthand, and I've encountered several places I could use it already.

[wadetregaskis]

@sspringer

When you change the z into a variable:

var z: Int? = 1
if (z != null) {
   println(z.dec()) // error because z might have changed in the meantime
}

In fairness to flow analysis, that seems like just a bug or limitation in Kotlin. There are cases where the compiler can't prove no mutations (e.g. you pass a mutable reference to 'z' to some opaque function, or the variable in question comes from an opaque or shared source), but those are relatively rare. In the above example, there's no way 'z' can mutate within those lines so there should not be (in principle) a compiler error.

[James_Dempsey]

@app-arianamini

@cal great points. It's worth considering the use of shorthand argument names (such as $0) within the if let statement, not sure about guard let.

There are a number of reasons why I do not think using a numbered placeholder variable shorthand like $0 would be a beneficial change.

First, one of the goals of the original if let shorthand proposal (SE-0345) was that its brevity encouraged clarity by not forcing a redeclaration of an already well-named variable.

Using numbered placeholder variables this way encourages code to use variables with names even less descriptive than proposal SE-0345 was trying to help developers avoid.

So, I think this sacrifices clarity over brevity.

Second, I think this would interact poorly with existing uses of $0, such as in closures:

if let customer.wishListItems {
     return $0.map { ShoppingCartItem($0) }
}

Third, in multi-condition conditional statements, it makes the order of the statements very brittle:

if let customers.first, let dailyDeals.first {
// $0 refers to unwrapped customers.first
// $1 refers to unwrapped dailyDeals.first
}

If you then needed to refer to an optional value in the optional customer, as well as the customer, you might do something like:

// Assuming unwrapped $0 would be valid in subsequent conditions
if let customers.first, let $0.loyaltyClubNumber, let dailyDeals.first {
// $0 refers to unwrapped customers.first
// $1 now refers to customers.first.loyaltyClubNumber
// $2 now refers to unwrapped dailyDeals.first
}

Depending on the code in the body, there may be a fair amount of renaming of the numbered variables.

Note that with closures, the type of the closure includes the order and type of the arguments that become the numbered variables. When part of an API, these change fairly rarely, so this is much less of an issue for numbered arguments in closures.

Finally, I think the existing consistency between if let and guard let is very important.

The consistency allows developers to choose between using if let and guard let based on what is best for the flow of their code, not based on one construct having different or more capabilities than the other.

Adding $0 to only if let could lead developers to use if let even when guard let would lead to cleaner or more readable code, only because the shortcut variable was desired. It additionally would add to the cognitive load of keeping track of things that will work with an if let that won’t work with a guard let.

So, I don’t think if let and guard let should diverge.

So, if this were added to if let, it should also be added to guard let. But, I think having the $0 variable work with guard let is problematic.

The existing named $0 in closures is typically used for closures with short bodies. I think that is also why thinking of using numbered placeholder variables is appealing for use in the body of an if statement.

With guard let however, the numbered variable persists for the lifetime of the containing scope. To remember which numbered variable is which, the developer needs to keep referring back to the earlier guard statements. Needing to tell $0, $1, and $2 apart further down in the body of a method with modest length does not promote clarity at the point of use.

This also brings up ordering issues. Very often developers will use separate guard statements to check for different conditions. I would imagine the numbered variables would need to be order-dependent and cumulative:

guard let customers.first else { print(“No customer available”); return }

guard let products.featuredProduct else { print(“No featured product”); return }

// $0 refers to unwrapped customers.first
// $1 refers to unwrapped featuredProduct

Adding, removing, or reordering the guard statements makes the use of the placeholder variables very brittle.

So, I don’t think it makes sense to add this for guard let and I don’t think the benefit is strong enough to make if let condition behavior diverge from guard let condition behavior.

For these reasons I don’t think that using numbered placeholder variables would work well for this proposal.

[James_Dempsey]

@Jon_Shier

I don't think that's a blocker for the pitch any more than the fact that if let one, let one = other.one leads to a conflict.

Yes, that point is the weakest of the three objections I posted.

It’s not a blocker but it adds potential friction that isn’t currently present.

It’s not likely anyone would ever manually type:
if let one, let one = other.one

because the developer just defined one a few keystrokes earlier.

With the current shorthand, writing the conditional will never lead to a naming conflict because the variable names in the containing scope are already unique.

With the proposed shorthand, using the proposed shorthand may or may not lead to a naming conflict, and whether it does is dependent on code often outside the local scope.

So, with this proposed shortcut, often I can use the shortcut, occasionally I can’t use the shortcut. And over time a naming error can stop my code from compiling because code potentially outside of my control has changed the name of a property. (With the fix to the compilation error being more than updating the property name, it requires editing a condition and the body of the conditional to introduce and use a new local variable with a non-conflicting name).

Again, not necessarily a deal-breaker, but definitely a consequence not present in the SE-0345 shorthand.

[sspringer (Stefan Springer)]

@wadetregaskis

In fairness to flow analysis, that seems like just a bug or limitation in Kotlin.

My example was too simplified or Kotlin got better in this regard in the meantime, but see the excerpt below from the Kotlin documentation. The point I wanted to make clear is that the handling of an optional might then change according to the result of such an analysis and I like it better if the treatment of an optional is "more stable" in the presence of according changes of the code around it, the distinction between optional and non-optional being the only guidance so to speak. So I like the Swift way much better. Simple, elegant solutions leading to clear code and not too much magic.

from the Kotlin documentation

Note that this only works where b is immutable (meaning it is a local variable that is not modified between the check and its usage or it is a member val that has a backing field and is not overridable), because otherwise it could be the case that b changes to null after the check.

[taylorswift]

@James_Dempsey

Needing to tell $0, $1, and $2 apart further down in the body of a method with modest length does not promote clarity at the point of use.

i personally have never had an issue with $0, $1, $2, etc. what is really awful is when $1, $2, etc. don’t exist, and we have to access tuple elements on $0, like in:

x.enumerated().map { y($0.0, $0.1) } 

sadly, this is hard to avoid. but let’s not hate on $1, $2, etc. merely by association.

[app-arianamini (Arian Amini)]

This pitch serves as an additional helper for developers, introducing localesFirst. While the name may not be ideal, developers will have the flexibility to provide their own custom names if desired.

In addition, it would be beneficial to include a compiler error to handle cases like nested maps. For example:

if let customer.wishListItems {
    return $0.map { ShoppingCartItem($0) }
}

The proposed compiler error message could be something like: "Contextual type for closure argument list expects 1 argument, which cannot be implicitly ignored." This error message would alert developers when they unintentionally ignore the closure argument list, similar to how nested maps are handled.

[James_Dempsey]

@taylorswift

@James_Dempsey

Needing to tell $0, $1, and $2 apart further down in the body of a method with modest length does not promote clarity at the point of use.

i personally have never had an issue with $0, $1, $2, etc. what is really awful is when $1, $2, etc. don’t exist, and we have to access tuple elements on $0, like in:

x.enumerated().map { y($0.0, $0.1) } 

sadly, this is hard to avoid. but let’s not hate on $1, $2, etc. merely by association.

I agree that in a short, terse closure body $0, $1, $2 etc. can be very clear.

I was saying that extending that to a longer method body, where the value of the numbered arguments depend on the number and order of multiple separate guard let statements, that further down the body it will be difficult to keep track of what each variable represents.

It would be analogous to naming the local variables in a method a1, a2, a3 etc.

But I’m not hating on the current usage of $0, $1, $2 in closures.

[tera]

@cal

Defining a let optionalValue binding for if let myOptionalObject?.optionalValue could be reasonable, but how could we handle more complex cases like:

if let property.myFunction() { ... }
if let myOptionalObject?.optionalValue.map({ $0.value }) { ... }
if let someArray[0] { ... }
if let myDictionary["dictionaryKey"] { ... }

I think it's reasonable to not support those complex cases, just the simple obvious case.

@cal

Would this sort of sugar pull its weight if it only worked for property accesses, and didn't support for these other types of cases?

I believe so.

@James_Dempsey

It also sets up the potential of conflicting implied names, for example:

guard let budgeted.total, let actual.total else { return }

or

guard let locales.first, let languages.first else { return }

Where the shorthand works on the first use but not the second.

This will be not any different compared to the full form:

guard let total = budgeted.total, let total = actual.total else { return }
guard let first = locales.first, let first = languages.first else { return }

which works today (the first binding is inaccessible).

A slightly more complicated (and somewhat more useful) example would be when you access the binding within the expression:

// root -> left -> left -> right -> left
if let node = root.left, let node = first.left, left node = first.right, let node = first.left {
    print(node)
}

which with the proposed shorthand notation becomes:

// root -> left -> left -> right -> left
if let root.left, let left.left, left left.right, let right.left {
    print(left)
}

or even simpler:

if let root.left?.left?.right?.left {
    print(left)
}

[app-arianamini (Arian Amini)]

Another consideration is the following:

if let optionalObject.optionalValue {
   // If 'optionalValue' is not nil -> assign it to a variable e.g. 'optionalValue' or use shorthand notation like '$0' or 'optionalObjectOptionalValue'.
   // Additionally, 'optionalObject' is now also unwrapped and ready to use.
} else {
}

[tera]

It should be with "?" after optionalObject:

if let optionalObject?.optionalValue {
}

which is equivalent to:

if let optionalValue = optionalObject?.optionalValue {
  doSomething(optionalValue)
  doSomethingElse(optionalObject)
}

strictly speaking even if you've got a non nil binding for optionalValue variable, optionalObject could still become nil (e.g. as a result of 'doSomething' or as a result of something happening on a different thread). Two bindings will be needed to have both variables non nil:

if let optionalObject = optionalObject, let optionalValue = optionalObject.optionalValue {
  doSomething(optionalValue)
  doSomethingElse(optionalObject)
}

which with the proposed shorthand notation becomes:

if let optionalObject, let optionalObject.optionalValue {
  doSomething(optionalValue)
  doSomethingElse(optionalObject)
}

[esummers (Eric)]

Although I think it would be great to see this for properties, I think the real solution would be JavaScript or Rust style de-structuring. However Swift would need to flesh out pattern matching for classes, structs, dictionaries, arrays, etc. for that.

[masture (Pankaj Kulkarni)]

This seems good short cut for the experienced programmers.
This is not easy to understand and increases the entry barrier to the Swift Programming Language.
I am afraid Swift is moving away from "Swift is friendly to new programmers".

[esummers (Eric)]

@esummers

However Swift would need to flesh out pattern matching for classes, structs, dictionaries, arrays, etc. for that.

I like the idea of a syntax that is based on closure capture lists for destructuring properties (structs, classes). It would be great to see an actual pitch based on this. It has been brought up a few times, but never pitched. This is the biggest item on my wish list for Swift that isn't already in progress.

Although I like the symmetry that Javascript has on structuring/destructuring, it is might be too late to do that for Swift. It would be nice to see out how destructuring dictionaries and arrays could fit in to this... Possibly the same bracket syntax could be used, but with different matching syntax inside.

Using closure capture list syntax for destructuring was brought up here:

[Pitch] Destructuring Assignment of Structs and Classes

This was discussed in a previous thread, and our consensus was that the closure capture list syntax would work best for this. For example final class C {} struct Car { let make: String let model: String let year: Int let reference: C } let car = Car(make: "Honda", model: "E", year: 2021, reference: C()) let [make, model, year] = car This would allow for binding to different names and also weak and unowned modifiers. This would also be less invasive to the parser I hope, sinc…

Just an idea based on above.

// Class / Struct properties
let [make, model, year] = car

if let [make, model, year] = car, year > 2014 {
  print("Make: \(make), Model: \(model)")
}

// Would carry a tuple type. Can override names like in a capture list.
let [carMake = make, model, year]: (String, String, Int) = car
// Nesting
let [
  policyHolder, 
  [make, model, year] = car
]: (String, (String, String, Int)) = autoPolicy 
// or maybe allow expressions
let [
  policyHolder, 
  make = car.make,
  model = car.model, 
  year = car.year,
]: (String, String, String, Int) = autoPolicy 

// Maybe extend for arrays with a slice-like ... syntax.
let [ a, b, c, ...theRest]: (Int?, Int?, Int?, ArraySlice<Int>) = [ 1, 2, 3, 4, 5]
let [ a, b, c, ...] = [ 1, 2, 3, 4, 5]
let [ a, b, c, ...]: (Int?, Int?, Int?) = [ 1, 2]
// Maybe destructure dictionaries
let [ "make": make, "model": model]: (String?, String?) = [ "make" : "Ford", "model": "Mach-E" ] 
// or subscript destructuring
let [ make = ["make"], model = ["model"]]: (String?, String?) = [ "make" : "Ford", "model": "Mach-E" ] 

Alternatively, maybe tuple destructuring could be extended for properties. That way square brackets could be reserved for Array/Dictionary destructuring and pattern matching. The slash is probably needed to avoid ambiguity during pattern matching and fits in with key path syntax.

let (\.make, \.model, \.year) = car

// allow renaming and nesting just like with tuples
if let (\.policyHolder, \.car: (\.make: carMake, \.model, \.year)) = autoPolicy, year > 2014 {
  print("\(policyHolder): \(carMake) \(model)")
}

// allow for named tuples with mismatched sizes
let (\.x, \.y) = (x: 1, y: 1, z: 1)

// a prefix character might be another option
let \(make, model, year) = car
let \{make, model, year} = car