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

[Tim Vermeulen]

>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
> }

This is simply a function to calculate the n-th Fibonacci number, though. The original code constructed a sequence.

> 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
> 
> 
>