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

This proposal runs counter to the spirit of what defer seems to be meant for in the first place. It’s to save you forgetting to do something (like closing a stream) before you exit a block of code. If you push it down in the code to after the return, then you might as well have just put the

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

While I can kind of see where you’re coming from I’m not sure about the change; the key thing about defer is that it doesn’t just execute in the cases you explicitly define, but can also occur if exceptions are thrown and other exit cases that could be all over the scope. To compare with other

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

Not sure I see how they're in different scopes. Can you explain that to me? -- E > On Jun 6, 2016, at 2:18 PM, donny wals wrote: > > 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

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

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

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

Hi, That’s fair enough. IMO structuring code so it reads in the same order it executes is an opportunity to simplify code rather than complicate it. However, I do agree that the fibonacci example I mentioned earlier might not be the best use case and it’s probably the best use case for this

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

Hi, I think that's an awful idea. I can already tell you that this will never be accepted. It just complicates the design and the semantics of the `defer` statement, and I don't see any advantage. Sorry. -Michael > Am 06.06.2016 um 22:14 schrieb donny wals via swift-evolution >

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

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

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

Michael, How would this proposal break your snippet? > func g(x: Int) { >defer { print("A"); } >let b: Int >if x == 3 { >return >} else { >b = x >} >defer { print("b is \(b)") } > } In this case if x==3 the function should return without executing the

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

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

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

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

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

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