>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<[email protected]>:
> >
> > 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
