[swift-evolution] [Proposal] A more liberal placement of defer

[Michael Peternell]

Hi,

you may think of `defer` as a function that pushes a block onto an implicit cleanup stack that is part of every lexical closure. On each scope exit, all blocks from its cleanup stack are popped and executed.

E.g.:

func f(x: Int) {
    defer { print("A"); }
    defer { print("B"); }
    if x == 3 {
        return
    }
    defer { print("C"); }
}

So, f(2) will print "CBA", but f(3) will print "BA" instead. Furthermore, this will change semantics and break the following code:

func g(x: Int) {
    defer { print("A"); }
    let b: Int
    if x == 3 {
        return
    } else {
        b = x
    }
    defer { print("b is \(b)") }
}

In the code above, b is only defined if x is not 3. If x is 3, the last `defer` block cannot be called, and that code would no longer compile.

So I think the current language behavior is more powerful. `defer` is usually used to do cleanup work, and it is called near the place where some resource is initialized. Putting a `defer` block to the end of a function kinda defeats its purpose. And simple functions like fibonacci I would just write without using `defer` at all - it's just confusing to use `defer` and `inout` in this case IMO.

/// Calculates the n'th fibonacci number. (n >= 1)
func fibonacci(n: Int) -> Int {
    var a = 0
    var b = 1
    for _ in 1...n {
        (a,b)=(b, a+b)
    }
    return a
}

Regards,
Michael


> Am 06.06.2016 um 21:50 schrieb donny wals via swift-evolution <swift-evolution at swift.org>:
> 
> Hi,
> 
> When we’re using defer we write some code that we want to execute the moment a scope exits.
> This leads to code that could read like:
> 
> let fibonacci = sequence(state: (0, 1)) { (pair: inout (Int, Int)) -> Int in
>    defer { pair = (pair.1, pair.0 + pair.1) }
>    return pair.0
> }
> 
> What I find strange about this is that we have to write the code that we want to execute after the return before the return.
> 
> I’d like to propose a change to defer that would allow the above code to be written as:
> 
> let fibonacci = sequence(state: (0, 1)) { (pair: inout (Int, Int)) -> Int in
>    return pair.0
>    defer { pair = (pair.1, pair.0 + pair.1) }
> }
> 
> This would make the intent of the code more clear (return first, then mutate state). Not all cases can benefit from this change, but anytime you exit a scope using a return I think it might be more clear to define the defer after the return. The code would more closely mirror the intent of the code.
> 
> A rule of thumb I’ve come up with for this is that whenever you’re using return to exit a scope, any defer in that same scope should be executed regardless of it’s position in that same scope. This proposal would supplement the way defer currently works.
> 
> What do you all think?
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution