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

[Erica Sadun]

This is problematic. You may want to defer code at different points with different reasons. For example, you might not want to trigger defer until after some preconditions have been met.:

guard something 
guard something
allocate memory; defer {release memory}

-- E



> On Jun 6, 2016, at 1:50 PM, donny wals via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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