[swift-evolution] Guaranteed closure execution

[Rod Brown]

I'm very supportive of this type of proposal.

I do agree with Brent though that @noescape and 'once' is somewhat orthogonal.

There are a lot of places where you want to be clear that the block will be called but no more than once. For example, the NSURLSession callback blocks you would expect never to be called multiple times. Completion handlers are almost always used only once. I don't think this case, which is extremely common, can be overlooked.

On the other hand, I suspect the majority of places you use closures with @noescape, it seems more likely you'd want it used multiple times, like a search, filter, find etc of multiple items in a collection or group, otherwise you'd generally just put the closured activity before or after. The only areas where I would expect to see such closures of @noescape and 'once' would be dispatch_sync, or somewhere where you want to invoke custom code in the middle of a complex operation of a method.

It seems to me that separating them, but allowing them to be used together, makes more sense.

Rod


> On 30 Jan 2016, at 5:05 AM, Félix Cloutier via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I don't have much to add but I also think that it would be nice to have.
> 
> Félix
> 
>> Le 29 janv. 2016 à 12:38:01, Chris Lattner via swift-evolution <swift-evolution at swift.org> a écrit :
>> 
>> On Jan 29, 2016, at 12:23 AM, Jacob Bandes-Storch via swift-evolution <swift-evolution at swift.org> wrote:
>>> I've wanted something like this as well. I think it would be harder than it seems, because "x = 1" might need to perform initialization, or assignment, depending how it's used.
>>> 
>>> It could make sense to have something like "@noescape(executed_exactly_once)" but this might be so limited it's not worth it. And I'm not sure how it should interact with throws.
>> 
>> I think that something like this is implementable, and making it a modifier to @noescape is sensible.
>> 
>> The semantics we could support is that the function is guaranteed to call the closure exactly once on any path that could lead to a return or throw.
>> 
>> This approach allows you to pass the closure down the stack, and composes with error handling.  It is obviously limited what you can do with the closure, but that is necessary to validate correctness.
>> 
>> -Chris
>> 
>> 
>> 
>>> 
>>> Jacob
>>> 
>>>> On Thu, Jan 28, 2016 at 11:38 PM, Gwendal Roué <swift-evolution at swift.org> wrote:
>>>> Hello,
>>>> 
>>>> I’d like to discuss the opportunity to let functions declare that a closure argument is guaranteed to have been executed when the function has returned.
>>>> 
>>>> For example:
>>>> 
>>>> 	func f(@noescape(executed) closure: () -> ()) {
>>>> 	    closure()
>>>> 	}
>>>> 
>>>> The expected advantage is that the compiler would know that a variable set inside the closure is guaranteed to be initialized, and that it can be used after the execution of the function, as below:
>>>> 
>>>> 	let x: Int  // Not initialized
>>>> 	f { x = 1 }
>>>> 	print(x)    // Guaranteed to be initialized
>>>> 
>>>> Today developers have to write pessimistic code like below:
>>>> 
>>>> 	var x: Int = 0 // `var` declaration, with some irrelevant value
>>>> 	f { x = 1 }
>>>> 	print(x)
>>>> 
>>>> As for a real world usage, I’d like to access a database in a safe (queued) way, and fetch values out of it:
>>>> 
>>>> 	let items: [Item]
>>>> 	let users: [User]
>>>> 	dbQueue.inDatabase { db in
>>>> 	    items = Item.all().fetchAll(db)
>>>> 	    users = Item.all().fetchAll(db)
>>>> 	}
>>>> 
>>>> Gwendal Roué
>>>> 
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160130/fb34d110/attachment.html>