[Pitch] Last expression as return value

[davedelong]

I would also like a serious thoughtful and well-reasoned answer to this. Both this proposal and SE-0380 seem to really be motivated by the elimination of immediately-executed closures.

But I have been unable to find any direct reference as to why that should be a goal, and what the issues with such closures are. In trying to get rid of them we're making the language vastly more complicated and ambiguous.

I'd appreciated it if the Core Team Language Steering Group would weigh in on why Immediately Executed Closures are seemingly "Bad™" and why we're going to such an effort to minimize their usage.

EDITED TO ADD:

1. This should've been directed at the Language Steering Group, not the Core Team.
2. The use of "serious" in the initial request is not implying that anything in here has been "unserious" before. I used it to specifically request answers that are thoughtful and convey an understanding of the nuance around the situation.

[Jumhyn (Frederick Kellison-Linn)]

SE-0380 has some direct discussion:

Finally, a closure can be used to simulate an if expression:

let bullet = {
    if isRoot && (count == 0 || !willExpand) { return "" }
    else if count == 0 { return "- " }
    else if maxDepth <= 0 { return "▹ " }
    else { return "▿ " }
}()

This also requires returns, plus some closure ceremony. But here the returns are more than ceremony – they require extra cognitive load to understand they are returning from a closure, not the outer function.

[ksluder (Kyle Sluder)]

But that’s not going to solve the problem of return in trailing closures, which is at least as big of an issue IMO:

func a() {
  for x in 0..<10 {
    print("\(x)") // prints 0 1 2 3 4 5
    if x == 5 {
      return
    }
  }

  print("this line never prints")
}

func b() {
  (0..<10).forEach {
    print("\(x)") // prints 0 1 2 3 4 5 6 7 8 9 10
    if x == 5 {
      return // does not affect behavior
    }
  }

  print("this line always prints")
}

Is this pitch trying to solve the wrong problem?

[Nevin]

@tera

What is the big nasty problem they caused and the better things we can do only because we have an alternative to that {…}()?

It adds two extra lines, it adds a level of indentation, it introduces a closure scope so you won’t be able to return from the outer function for example, and it’s ugly.

Counterpoint: this is the correct level of syntactic salt to discourage people from stuffing many lines of logic into a single in-place expression, while still making it possible to do so when necessary.

Four characters in “{}()” is quite short, so the amount of salt is small.

The scoping from the braces and the extra level of indentation together make it abundantly clear which statements are grouped together.

Within each branch of an if or switch expression it is already impossible to return from an outer function, so the closure scope has no effect on that.

Being “ugly” is entirely subjective. An immediately-called closure uses the same braces and parentheses for scopes and function calls as the rest of the language. It is standard Swift syntax composed in a standard way.

[taylorswift]

@Nevin

Four characters in “{}()” is quite short, so the amount of salt is small.

i remember in ancient times, the worry was that the optimizer didn’t understand these, and so people trained themselves to avoid immediately executed closure literals.

i doubt these concerns are valid today, although i wish Swift Godbolt were still online so we could actually check to be sure.

i think immediately-executed closure literals are a completely fine pattern today.

[Joe_Groff]

Immediately-applied closures and local functions are at most a function call; they should never allocate a closure. In optimized builds, since they are generally single-use private functions, they should normally be inlined as well.

[tera]

The scoping from the braces and the extra level of indentation together make it abundantly clear which statements are grouped together.

The single expression that could be an if that spans across 20 lines. If you want to put a single print log statement before that if you’d have to embed this if inside a {}() - indenting all those lines. And then you remove that print - you’ll have to indent it back. This is a huge deal IMHO.

Within each branch of an if or switch expression it is already impossible to return from an outer function, so the closure scope has no effect on that.

I was thinking about “do” expressions. I do not see this mentioned in the pitch - do they also prohibit returns?

Being “ugly” is entirely subjective

Probably. To my eye the ugly thing about it is this: }(. I believe for the similar reason we’ve got the syntax optimisation of trailing closures to not have }) sequence.

[sspringer (Stefan Springer)]

@ksluder

But that’s not going to solve the problem of return in trailing closures

There are places where closures make sense, and places where they do not, and for-loops are of the second type. Do not use forEach, use for-in loops instead.

…Which actually shows that you can write some bad code today. Just let people be able to drop the “return” as is proposed here and let’s find out how that will be used in a good way. Do not fear bad code, just don’t write it.

[Nevin]

@taylorswift

i wish Swift Godbolt were still online so we could actually check to be sure.

Wait, does https://swift.godbolt.org not work for you? It works fine for me.

@tera

The single expression that could be an if that spans across 20 lines. If you want to put a single print log statement before that if you’d have to embed this if inside a {}() - indenting all those lines. And then you remove that print - you’ll have to indent it back. This is a huge deal IMHO.

…are you talking about having a 20-line if-expression within a case of a switch expression, all placed in-line somewhere?

I don’t think we want to encourage that pattern.

[taylorswift]

@Nevin

Wait, does https://swift.godbolt.org not work for you? It works fine for me.

the last version of Swift that was supported on Godbolt was Swift 5.10.

[Mordil (Nathan Harris)]

That's because it's driven by community support IIRC. We just need to submit a change that adds support for Swift 6

[allevato (Tony Allevato)]

@taylorswift

the last version of Swift that was supported on Godbolt was Swift 5.10.

I'm not sure why the 6.0 release isn't on there, but the nightlies are still recent. If I add -v to my invocation there, I get:

Swift version 6.2-dev (LLVM 06a77c5cc0ff511, Swift f7fb0991b79fcda)

[DanL]

func a() {
    for x in 0..<10 {
        print("\(x)") // prints 0 1 2 3 4 5
        if x == 5 {
            return
        }
    }
    
    print("this line never prints")
}

Wouldn't it be nice if that function could be written like this:

func c() {
    for x in 0..<10 while x < 6 {
        print("\(x)") // prints 0 1 2 3 4 5
    }
    
    print("this line always prints")
}

Or like this:

func d() {
    for x in 0..<10 repeat {
        print("\(x)") // prints 0 1 2 3 4 5
    } while x < 5
    
    print("this line always prints")
}

[ben-cohen (BenC)]

@tera

I was thinking about “do” expressions. I do not see this mentioned in the pitch - do they also prohibit returns?

do expressions would prohibit returns, just like if and switch. I'll clarify in the proposal.

[Pampel]

@vns

Consequently, this would allow more complex if and switch expressions, just because now do expression can be used in a branch to execute several statements. And the major distinction I see in that approach is that now you have to explicitly reach for this feature.

Is this variation of do feasible? Apologies if it's been mentioned before, it's hard to search for individual ideas.

By itself...

let sandwich: Sandwich = do {
    let leaves = chooseLeaves()
    let meat = chooseMeat()
    let cheese = chooseCheese()
    
    Sandwich([leaves, meat, cheese], on: .wholemeal)
}

In if/else expressions...

let goForWalk = if isSunny do {
    let temperature = getTemperature()
    temperature > 15 && temperature < 40
} else if isOvercast do {
    let cloudiness = getCloudiness()
    cloudiness < 0.8
} else if isRaining {
    false
} else do {
    let coinFlip = flipACoin()
    coinFlip.isHeads
}

And switches...

let dinner = switch day {
    case .monday, .thursday: Curry()
    case .tuesday, .wednesday: Chilli()
    case .friday: Falafel()
    case .saturday: do {
        let leaves = chooseLeaves()
        let meat = chooseMeat()
        let cheese = chooseCheese()
        
        Sandwich([leaves, meat, cheese], on: .wholemeal)
    }
    case .sunday: Salad()
}

[ben-cohen (BenC)]

@Pampel

Is this variation of do feasible? Apologies if it's been mentioned before, it's hard to search for individual ideas.

Of these 3 snippets you give: the first ("by itself") is the feature as proposed.

The third ("switches") would also work as proposed – but is unnecessary in this proposal because you could just write

case .saturday:
  let leaves = chooseLeaves()
  let meat = chooseMeat()
  let cheese = chooseCheese()
   // last expression in case is value of this case
  Sandwich([leaves, meat, cheese], on: .wholemeal)

As I mentioned here, there's another formulation of this proposal where do expressions are the only thing that gets the "last value" treatment. They could then be used with single-expression-body switch expressions "as is" like in your snippet.

The if one is the one that isn't quite so simple:

let goForWalk = if isSunny do {
    let temperature = getTemperature()
    temperature > 15 && temperature < 40
}

With the "only do can be multi-statement", this would need to be

let goForWalk = if isSunny {
  do {
    let temperature = getTemperature()
    temperature > 15 && temperature < 40
  }
} else { ... }

but I expect this could fairly easily be sugared to elide the outer braces and have if predicate do { be a thing.

[Pampel]

@ben-cohen

Of these 3 snippets you give: the first ("by itself") is the feature as proposed.

Sorry, I only included that so it was a complete summary.

I just liked the idea of do as a single keyword that would allow consistent wrapping of expressions that had an implicit return. It's not necessary in the switch, but it makes things consistent. In the if/else, it gets ride of the need for the extra/awkward indentation and braces in your unsugared example.

[SlugFiller (Saar Korren)]

@Panajev

would anyone mind to help me understand why that in and of itself is a serious pain point?

@davedelong

I would also like a serious answer to this

1. return changes its meaning
2. You cannot use return in its original meaning, since unlike break there's no such thing as a labelled return
3. You can't use a labelled break with a label outside of the closure. At the top level of the closure, break is a syntax error.
4. If the closure is inside an async function, and part of the expression requires await, {...}() becomes await (() async -> Type)({...}())
5. It makes reasoning about isolation, escapability, and copyability of local variables a lot more difficult. You may need to add extra decorations to indicate what is captured and how, when the original intention was just for a block of code to run.

Overall, Swift has a lot of syntactic sugar to hide the difference between a closure and a block of code. However, the difference between the two is far more than just syntax, and trying to sweep it under the rug is an invitation for footguns.

On the subject of do, I actually think it would be good if this worked:

let value: Int = if condition do {
  print("branch 1")
  1
}
else do {
  print("branch 2")
  2
}

And this didn't:

let value: Int = if condition {
  do {
    print("branch 1")
    1
  } // Error: Cannot convert Void to Int
}
else {
  do {
    print("branch 2")
    2
  }
}

By allowing only the "syntax error" to have new behavior, you make source compatibility a non-issue.

[Nobody1707]

Making do blocks into expressions, which this pitch does, literally allows it to do everything the then pitch could do. It just removes the need to write then.

This pitch allows:

let x = do {
   try Thing()
} catch {
    defaultThing
}

[Nobody1707]

What exactly do think is different here? Both versions require the do branch and each of the catch branches to return the same type, even if the top quote doesn't explicitly mention it.