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
> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
