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

___
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

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?

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

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

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

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

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

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

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

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

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