Re: [swift-evolution] Better syntax for deferred?

[John McCall via swift-evolution]

> On Jan 4, 2016, at 12:41 PM, Howard Lovatt via swift-evolution 
>  wrote:
> I don’t think it is worth changing from defer to the more traditional try 
> finally block, both have pros and cons. Just work with what we have. You can 
> always, as a matter of style, put a single defer block at the end of scope 
> instead of multiple defers throughout the block.

For what it’s worth, the error-handling rationale discusses the trade-offs of 
the defer syntax.  I think we’re very happy with the current syntax.

John.

> 
> 
>> On 5 Jan 2016, at 1:17 AM, Jeremy Pereira via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> 
>>> On 2 Jan 2016, at 16:49, Maury Markowitz via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
 On Jan 2, 2016, at 9:38 AM, Nicky Gerritsen >>> > wrote:
 
 Defer is used to make code *always* run, even if the function terminates 
 early. Imagine:
>>> 
>>> Which is precisely why I called it 'always'. So in your example:
>>> 
>>>   func doSomethingWith(x: Int) {
>>> print(“1”)
>>> defer { print(“2") }
>>> if x > 3 { defer { print(“yay”); return }
>>> print(“3”)
>>>   }
>>> 
>>> I would say:
>>> 
>>>   func doSomethingWith(x: Int) {
>>> print(“1”)
>>> print(“3”)
>>>   always {
>>>   print(“2")
>>>   if x > 3 { print(“yay”) }
>>>   }
>>>   }
>>> 
>>> This is functionally identical, but both the syntax and program flow are 
>>> greatly improved.
>> 
>> No your example is not functionally identical to Nicky’s (notwithstanding 
>> the missing closing brace in the original). “defer" defers the closure to 
>> the end of the current scope. In this instance , that is the end of the if 
>> block. The “yay” must come before the “2” because the if scope exits before 
>> the function scope. Also, in the following:
>> 
>> func doSomethingWith(x: Int) {
>>print("1")
>>defer { print("2") }
>>if x > 3 { defer { print("yay") } }
>>print("3")
>> }
>> 
>> doSomethingWith(4)
>> 
>> “yay” comes before “3” for the same reason.
>> 
>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Better syntax for deferred?

[Howard Lovatt via swift-evolution]

I don’t think it is worth changing from defer to the more traditional try 
finally block, both have pros and cons. Just work with what we have. You can 
always, as a matter of style, put a single defer block at the end of scope 
instead of multiple defers throughout the block.


> On 5 Jan 2016, at 1:17 AM, Jeremy Pereira via swift-evolution 
>  wrote:
> 
>> 
>> On 2 Jan 2016, at 16:49, Maury Markowitz via swift-evolution 
>>  wrote:
>> 
>>> On Jan 2, 2016, at 9:38 AM, Nicky Gerritsen  wrote:
>>> 
>>> Defer is used to make code *always* run, even if the function terminates 
>>> early. Imagine:
>> 
>> Which is precisely why I called it 'always'. So in your example:
>> 
>>   func doSomethingWith(x: Int) {
>>  print(“1”)
>>  defer { print(“2") }
>>  if x > 3 { defer { print(“yay”); return }
>>  print(“3”)
>>   }
>> 
>> I would say:
>> 
>>   func doSomethingWith(x: Int) {
>>  print(“1”)
>>  print(“3”)
>>   always {
>>   print(“2")
>>   if x > 3 { print(“yay”) }
>>   }
>>   }
>> 
>> This is functionally identical, but both the syntax and program flow are 
>> greatly improved.
> 
> No your example is not functionally identical to Nicky’s (notwithstanding the 
> missing closing brace in the original). “defer" defers the closure to the end 
> of the current scope. In this instance , that is the end of the if block. The 
> “yay” must come before the “2” because the if scope exits before the function 
> scope. Also, in the following:
> 
> func doSomethingWith(x: Int) {
>print("1")
>defer { print("2") }
>if x > 3 { defer { print("yay") } }
>print("3")
> }
> 
> doSomethingWith(4)
> 
> “yay” comes before “3” for the same reason.
> 
> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Better syntax for deferred?

[Jeremy Pereira via swift-evolution]

> On 2 Jan 2016, at 16:49, Maury Markowitz via swift-evolution 
>  wrote:
> 
>> On Jan 2, 2016, at 9:38 AM, Nicky Gerritsen  wrote:
>> 
>> Defer is used to make code *always* run, even if the function terminates 
>> early. Imagine:
> 
> Which is precisely why I called it 'always'. So in your example:
> 
>func doSomethingWith(x: Int) {
>   print(“1”)
>   defer { print(“2") }
>   if x > 3 { defer { print(“yay”); return }
>   print(“3”)
>}
> 
> I would say:
> 
>func doSomethingWith(x: Int) {
>   print(“1”)
>   print(“3”)
>always {
>print(“2")
>if x > 3 { print(“yay”) }
>}
>}
> 
> This is functionally identical, but both the syntax and program flow are 
> greatly improved.

No your example is not functionally identical to Nicky’s (notwithstanding the 
missing closing brace in the original). “defer" defers the closure to the end 
of the current scope. In this instance , that is the end of the if block. The 
“yay” must come before the “2” because the if scope exits before the function 
scope. Also, in the following:

 func doSomethingWith(x: Int) {
print("1")
defer { print("2") }
if x > 3 { defer { print("yay") } }
print("3")
 }

doSomethingWith(4)

“yay” comes before “3” for the same reason.


> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Better syntax for deferred?

[Robert S Mozayeni via swift-evolution]

Not only that, but placing defer at the end of a scope, where any other code 
may never get executed if there’s an early return, kind of violates the whole 
concept of control flow.

func f() throws {
let o = file(path: "")
o.openFile()
do {
try o.write(self.data)
}

print("success")
always { o.close() }
}

What happens if o.write fails? Going with always would imply that we either…

A) put the `always` in every possible place the scope might exit, defeating the 
whole purpose of defer/always. Maury, I’m assuming you’re not actually 
suggesting that, which would leave: B) if the main scope of the function exits 
at any point, drop down to the `always` at the end of the scope and execute it. 
But then, what about the surrounding code at the end of the main scope? Like I 
said, I think this would violate the whole concept of control flow by 
cherry-picking a specific type of command that is always executed within a 
scope, even if that command is in some place the control flow doesn’t reach.

Unless I’m misinterpreting something (let me know if I am) this seems less 
intuitive than `defer` was to begin with.

-Robert


> On Jan 2, 2016, at 3:17 PM, Dennis Lysenko via swift-evolution 
>  wrote:
> 
> Deferring at the end of the function removes the ability to defer actions on 
> variables introduced in an inner scope.
> 
> 
> On Sat, Jan 2, 2016, 1:57 PM Tino Heth via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> I have the terrible feeling something is wrong with my posts so that they get 
> caught by spamfilters or similar…
> 
> But as others stated as well:
> defer has a use case that is a little bit different from what you want to 
> archive.
> 
> > Why not use a solution that is widely used and better?
> I'm curious:
> Which languages have this "always" construct?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Better syntax for deferred?

[Robert S Mozayeni via swift-evolution]

(Sorry if you get this email twice, I realized I first sent it from an email 
address that is not the one I used to subscribe to this list)

Not only that, but placing defer at the end of a scope, where any other code 
may never get executed if there’s an early return, kind of violates the whole 
concept of control flow.

func f() throws {
let o = file(path: "")
o.openFile()
do {
try o.write(self.data)
}

print("success")
always { o.close() }
}

What happens if o.write fails? Going with always would imply that we either…

A) put the `always` in every possible place the scope might exit, defeating the 
whole purpose of defer/always. Maury, I’m assuming you’re not actually 
suggesting that, which would leave: B) if the main scope of the function exits 
at any point, drop down to the `always` at the end of the scope and execute it. 
But then, what about the surrounding code at the end of the main scope? Like I 
said, I think this would violate the whole concept of control flow by 
cherry-picking a specific type of command that is always executed within a 
scope, even if that command is in some place the control flow doesn’t reach.

Unless I’m misinterpreting something (let me know if I am) this seems less 
intuitive than `defer` was to begin with.

-Robert

> On Jan 2, 2016, at 3:17 PM, Dennis Lysenko via swift-evolution 
>  wrote:
> 
> Deferring at the end of the function removes the ability to defer actions on 
> variables introduced in an inner scope.
> 
> 
> On Sat, Jan 2, 2016, 1:57 PM Tino Heth via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> I have the terrible feeling something is wrong with my posts so that they get 
> caught by spamfilters or similar…
> 
> But as others stated as well:
> defer has a use case that is a little bit different from what you want to 
> archive.
> 
> > Why not use a solution that is widely used and better?
> I'm curious:
> Which languages have this "always" construct?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Better syntax for deferred?

[Developer via swift-evolution]

-1. `defer` doesn’t exist just to execute code at the end of blocks, it exists 
to allow resource cleanup when you have a function with multiple return points 
or non-trivial scoping.  For example, let’s add an if statement to your code:


func clear() {
   print("1")
   print("3")
   if (theBusiness) {
   print(“4”)
   return
   }
   always { print("2") }
}

Now `always` does not, in fact, model the flow of control through this function 
and I’m confused about where that finalizer is going to run.  I mean, because 
it is declared below the if, will it never execute?  Will it always execute as 
the name implies?  But couldn’t control flow branch before that statement is 
hit?  It’s a context switch I don’t have to make with `defer` as it currently 
stands.

> On Jan 2, 2016, at 7:25 AM, Maury Markowitz via swift-evolution 
>  wrote:
> 
> I'm confused about 'defer'. Not the purpose, the chosen syntax. 
> 
> func confusing() {
>print("1")
>defer { print("2") }
>print("3")
> }
> 
> Produces 1,3,2. Trying to describe what is happening here is non-trivial... 
> it runs line 1, then we put line 2 on a stack, then line three runs, then we 
> pop the stack... what?! And stepping through it in the debugger... ugh.
> 
> Unless I missed something obvious, wouldn't placing "code that always has to 
> run at the end" actually *at the end* not make more sense? Like this...
> 
> func clear() {
>print("1")
>print("3")
> 
>always { print("2") }
> }
> 
> Not only is the code clearly expressing its intent, the actual execution is 
> following the source.
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Better syntax for deferred?

[Charles Srstka via swift-evolution]

> On Jan 2, 2016, at 8:37 AM, Tino Heth via swift-evolution 
>  wrote:
> 
>> 
>> Unless I missed something obvious, wouldn't placing "code that always has to 
>> run at the end" actually *at the end* not make more sense? Like this…
> In most cases, you use defer for cleanup tasks - so it make more sense to 
> keep it at the source of the "problem":
> 
> file.open(); defer { file.close() }
> …
> 
> Tino

This. It’s way easier to remember to do necessary cleanup tasks if you add the 
cleanup call right after the call that requires the cleanup. It’s also much 
easier to catch cases where someone has forgotten to do so. Separating the init 
and cleanup by large distances as in the old try/catch/finally mechanism makes 
it easier for things to get out of sync as the code evolves.

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Better syntax for deferred?

[Dennis Lysenko via swift-evolution]

Deferring at the end of the function removes the ability to defer actions
on variables introduced in an inner scope.

On Sat, Jan 2, 2016, 1:57 PM Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

> I have the terrible feeling something is wrong with my posts so that they
> get caught by spamfilters or similar…
>
> But as others stated as well:
> defer has a use case that is a little bit different from what you want to
> archive.
>
> > Why not use a solution that is widely used and better?
> I'm curious:
> Which languages have this "always" construct?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Better syntax for deferred?

[Tino Heth via swift-evolution]

I have the terrible feeling something is wrong with my posts so that they get 
caught by spamfilters or similar…

But as others stated as well:
defer has a use case that is a little bit different from what you want to 
archive.

> Why not use a solution that is widely used and better?
I'm curious:
Which languages have this "always" construct?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Better syntax for deferred?

[Michel Fortin via swift-evolution]

Le 2 janv. 2016 à 13:29, Maury Markowitz via swift-evolution 
 a écrit :

> No, they don't. With the exception of "Go", I'm unfamiliar with any other 
> language that implements this feature *in this fashion*.

D has `scope (exit)`, which is exactly the same as `defer` in Swift.

It's also common to see C++ code using scope guards (implemented as a library 
feature). As far as I'm aware, this is where the pattern emerged first.

-- 
Michel Fortin
https://michelf.ca

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Better syntax for deferred?

[Michel Fortin via swift-evolution]

Le 2 janv. 2016 à 9:25, Maury Markowitz via swift-evolution 
 a écrit :

> I'm confused about 'defer'. Not the purpose, the chosen syntax. 
> 
> func confusing() {
>print("1")
>defer { print("2") }
>print("3")
> }
> 
> Produces 1,3,2. Trying to describe what is happening here is non-trivial... 
> it runs line 1, then we put line 2 on a stack, then line three runs, then we 
> pop the stack... what?! And stepping through it in the debugger... ugh.
> 
> Unless I missed something obvious, wouldn't placing "code that always has to 
> run at the end" actually *at the end* not make more sense? Like this...
> 
> func clear() {
>print("1")
>print("3")
> 
>always { print("2") }
> }
> 
> Not only is the code clearly expressing its intent, the actual execution is 
> following the source.

With your proposal, code like this:

func test() throws -> T {
let a = try makeSomething()
defer { a.cleanup() }

let b = try makeSomething()
defer { b.cleanup() }

return try compute(a, b)
}

would have to be rewritten somewhat like this:

func test() throws -> T {
let a = try makeSomething()
do {
let b = try makeSomething()
do {
return try compute(a, b)
always { b.cleanup() }
}
always { a.cleanup() }
}
}

which is a bit inconvenient. One important thing with `defer` is that where you 
put it in the function impacts at which point it gets pushed on the "cleanup 
stack", something that gets lost with `always` and which I need to add back 
through `do {}` blocks here.

I think what you are looking for is a `do {} finally {}` block, which you 
should feel free to propose if you think it's worth it. I personally don't 
think it makes the above example better, but it certainly has the benefit of 
always running things in source order.

func test() throws -> T {
let a = try makeSomething()
do {
let b = try makeSomething()
do {
return try compute(a, b)
} finally {
b.cleanup()
}
} finally {
a.cleanup()
}
}

-- 
Michel Fortin
https://michelf.ca

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Better syntax for deferred?

[Maury Markowitz via swift-evolution]

> On Jan 2, 2016, at 1:26 PM, Javier Soto  wrote:
> 
> How would always behave if the function has an early return?

Exactly the same way as 'defer' would behave if the function has an early 
return.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Better syntax for deferred?

[Maury Markowitz via swift-evolution]

> On Jan 2, 2016, at 12:56 PM, Tim Hawkins  wrote:
> 
> Again my 2 cents
> 
> Other languages use "deffer", and have very simular semantics

No, they don't. With the exception of "Go", I'm unfamiliar with any other 
language that implements this feature *in this fashion*.

> there is no benifit gained from being different, and it makes peoples task of 
> transfering from other systems easier.

Precisely why I make this suggestion. Swift is the oddball here, using 
something that is decidedly non-standard as well as confusing. Why not use a 
solution that is widely used and better?

> What is there works just fine and achives the result it was designed to do. 
> Why do we need to change it?

The same could be said for Obj-C, yet here we are.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Better syntax for deferred?

[Javier Soto via swift-evolution]

How would always behave if the function has an early return? Like so:

func testAlways(x: Int) {
print("non-deferred call")
return
let a = 3
always {
print("deferred call: \(a)")
}
}
On Sat, Jan 2, 2016 at 9:56 AM Tim Hawkins via swift-evolution <
swift-evolution@swift.org> wrote:

> Again my 2 cents
>
> Other languages use "deffer", and have very simular semantics, there is no
> benifit gained from being different, and it makes peoples task of
> transfering from other systems easier.
>
> The percieved "simplicity" of the alternative semanatics and naming is
> subjective. What is there works just fine and achives the result it was
> designed to do. Why do we need to change it?
> On Jan 3, 2016 1:47 AM, "Maury Markowitz via swift-evolution" <
> swift-evolution@swift.org> wrote:
>
>>
>> > On Jan 2, 2016, at 11:48 AM, Sebastian Mecklenburg via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >
>> > I don’t think it’s confusing, I read ‘defer’ a ‘do it later’ and that’s
>> just what it does. And the deferred calls are not always necessary so they
>> can’t always be placed at the end.
>>
>> Can you be more specific about "deferred calls are not always necessary"?
>> Do you mean that you could, for instance, place an if in front of the
>> defer? If so one could do the same with always, of course. I'll use your
>> example, slightly expanded, to illustrate
>>
>> > func testDefer(x: Int) {
>> >defer {print("deferred call1")}
>> >if x > 1 { defer {print("deferred call2")} }
>> print("non-deferred call")
>> > }
>>
>> I would rewrite this as:
>>
>> func testAlways(x: Int) {
>> print("non-deferred call")
>> always {
>> print("deferred call1")
>> if x > 1 print("deferred call2")
>> }
>> }
>>
>> Which is 100% equivalent to your example, but works precisely as you
>> would expect without needing to "be aware" of any "logical consequence"s.
>> The code runs exactly as it appears.
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
Javier Soto
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Better syntax for deferred?

[Tim Hawkins via swift-evolution]

Again my 2 cents

Other languages use "deffer", and have very simular semantics, there is no
benifit gained from being different, and it makes peoples task of
transfering from other systems easier.

The percieved "simplicity" of the alternative semanatics and naming is
subjective. What is there works just fine and achives the result it was
designed to do. Why do we need to change it?
On Jan 3, 2016 1:47 AM, "Maury Markowitz via swift-evolution" <
swift-evolution@swift.org> wrote:

>
> > On Jan 2, 2016, at 11:48 AM, Sebastian Mecklenburg via swift-evolution <
> swift-evolution@swift.org> wrote:
> >
> > I don’t think it’s confusing, I read ‘defer’ a ‘do it later’ and that’s
> just what it does. And the deferred calls are not always necessary so they
> can’t always be placed at the end.
>
> Can you be more specific about "deferred calls are not always necessary"?
> Do you mean that you could, for instance, place an if in front of the
> defer? If so one could do the same with always, of course. I'll use your
> example, slightly expanded, to illustrate
>
> > func testDefer(x: Int) {
> >defer {print("deferred call1")}
> >if x > 1 { defer {print("deferred call2")} }
> print("non-deferred call")
> > }
>
> I would rewrite this as:
>
> func testAlways(x: Int) {
> print("non-deferred call")
> always {
> print("deferred call1")
> if x > 1 print("deferred call2")
> }
> }
>
> Which is 100% equivalent to your example, but works precisely as you would
> expect without needing to "be aware" of any "logical consequence"s. The
> code runs exactly as it appears.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Better syntax for deferred?

[Maury Markowitz via swift-evolution]

> On Jan 2, 2016, at 11:48 AM, Sebastian Mecklenburg via swift-evolution 
>  wrote:
> 
> I don’t think it’s confusing, I read ‘defer’ a ‘do it later’ and that’s just 
> what it does. And the deferred calls are not always necessary so they can’t 
> always be placed at the end.

Can you be more specific about "deferred calls are not always necessary"? Do 
you mean that you could, for instance, place an if in front of the defer? If so 
one could do the same with always, of course. I'll use your example, slightly 
expanded, to illustrate

> func testDefer(x: Int) {
>defer {print("deferred call1")}
>if x > 1 { defer {print("deferred call2")} }
print("non-deferred call")
> }

I would rewrite this as:

func testAlways(x: Int) {
print("non-deferred call")
always {
print("deferred call1")
if x > 1 print("deferred call2")
}
}

Which is 100% equivalent to your example, but works precisely as you would 
expect without needing to "be aware" of any "logical consequence"s. The code 
runs exactly as it appears.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Better syntax for deferred?

[Sebastian Mecklenburg via swift-evolution]

I don’t think it’s confusing, I read ‘defer’ a ‘do it later’ and that’s just 
what it does. And the deferred calls are not always necessary so they can’t 
always be placed at the end.

The only thing to be aware of is that the order is reversed (or not 
determined), so

func testDefer() {
defer {print("deferred call1")}
defer {print("deferred call2")}
}

prints

deferred call2
deferred call1

But I think that is the logical consequence of the way how defer is supposed to 
work, so that’s OK too. One just has to be aware of it.

> On 02 Jan 2016, at 15:25, Maury Markowitz via swift-evolution 
>  wrote:
> 
> I'm confused about 'defer'. Not the purpose, the chosen syntax. 
> 
> func confusing() {
>print("1")
>defer { print("2") }
>print("3")
> }
> 
> Produces 1,3,2. Trying to describe what is happening here is non-trivial... 
> it runs line 1, then we put line 2 on a stack, then line three runs, then we 
> pop the stack... what?! And stepping through it in the debugger... ugh.
> 
> Unless I missed something obvious, wouldn't placing "code that always has to 
> run at the end" actually *at the end* not make more sense? Like this...
> 
> func clear() {
>print("1")
>print("3")
> 
>always { print("2") }
> }
> 
> Not only is the code clearly expressing its intent, the actual execution is 
> following the source.
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Better syntax for deferred?

[Maury Markowitz via swift-evolution]

> On Jan 2, 2016, at 9:38 AM, Nicky Gerritsen  wrote:
> 
> Defer is used to make code *always* run, even if the function terminates 
> early. Imagine:

Which is precisely why I called it 'always'. So in your example:

func doSomethingWith(x: Int) {
print(“1”)
defer { print(“2") }
if x > 3 { defer { print(“yay”); return }
print(“3”)
}

I would say:

func doSomethingWith(x: Int) {
print(“1”)
print(“3”)
always {
print(“2")
if x > 3 { print(“yay”) }
}
}

This is functionally identical, but both the syntax and program flow are 
greatly improved.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Better syntax for deferred?

[Nicky Gerritsen via swift-evolution]

Defer is used to make code *always* run, even if the function terminates early. 
Imagine:

func doSomethingWith(x: Int) {
print(“1”)
defer { print(“2") }
if x > 3 { defer { print(“yay”); return }
print(“3”)
}

Now print(“2”) will always happen, even if the if is true. Placing it at the 
end this will not be the case. The “yay” will only be printed in the case of 
the if.
In general we can not place the defer at the end, because it only should run if 
the code “comes by” the call.

Regards,

Nicky

> On 2 jan. 2016, at 15:25, Maury Markowitz via swift-evolution 
>  wrote:
> 
> I'm confused about 'defer'. Not the purpose, the chosen syntax.
> 
> func confusing() {
>print("1")
>defer { print("2") }
>print("3")
> }
> 
> Produces 1,3,2. Trying to describe what is happening here is non-trivial... 
> it runs line 1, then we put line 2 on a stack, then line three runs, then we 
> pop the stack... what?! And stepping through it in the debugger... ugh.
> 
> Unless I missed something obvious, wouldn't placing "code that always has to 
> run at the end" actually *at the end* not make more sense? Like this...
> 
> func clear() {
>print("1")
>print("3")
> 
>always { print("2") }
> }
> 
> Not only is the code clearly expressing its intent, the actual execution is 
> following the source.
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Better syntax for deferred?

[Tino Heth via swift-evolution]

> Unless I missed something obvious, wouldn't placing "code that always has to 
> run at the end" actually *at the end* not make more sense? Like this…
In most cases, you use defer for cleanup tasks - so it make more sense to keep 
it at the source of the "problem":

file.open(); defer { file.close() }
…

Tino
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution