[swift-evolution] Guaranteed closure execution

[Timothy Wood]

Oh, and I forgot to mention that this would mean deinit would need to extract the block it it hadn't been done already. I would hope (to avoid silent errors) that the compiler would require a reference type with an @once property to have a deinit that checks for a lingering value and deals with it. This would have avoided a few bugs over the years...

-tim

> On Apr 23, 2016, at 9:33 AM, Timothy Wood via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> 
>> On Apr 23, 2016, at 5:56 AM, Gwendal Roué via swift-evolution <swift-evolution at swift.org>
> [...]
>> 
>> Since @once actually implies @noescape (as described earlier in the thread), it can be shortened to:
> [...]
> 
> I'm surprised that @once would imply @noescape. In my opinion this makes it much less useful. For example, it is common to have asynchronous operations with a completion handler -- the completion handler will definitely escape and should definitely get called once.
> 
> In some cases the completion handler may get passed to other functions that take an @once block, so that should count as passing off your responsibility to call it.
> 
> In other cases, it may get stored in an object representing a long-lived async operation. This is trickier, but I would hope that a nullable var property, only in a reference type, could be marked @once. Reading that property would return an @once block *and* clear the property (so you'd be back to needing to call it or pass it away). It is unclear if only closure properties should be allowed to be marked @once, but presumable the implementation cloud support any type.
> 
> A simple noescape @once might find a few trivial uses in my codebase, but the really hard to diagnose bugs have been in async code where escaping is natural and necessary.
> 
> -tim
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution