Erica,
Maybe my phrasing was a bit off, but in my proposal it’s really important that
the return and the defer are in the same scope. In your example the allocate
memory line is in a different scope that the guard/else statements. Therefor,
the defer { release memory } shouldn’t be executed if the guards don’t hold.
D
> On 06 Jun 2016, at 22:09, Erica Sadun <[email protected]> wrote:
>
> 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
