[swift-evolution] Guaranteed closure execution

[Chris Lattner]

> On Feb 3, 2016, at 4:45 PM, Dany St-Amant via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> Le 3 févr. 2016 à 19:22, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>> 
>> 
>>> On Feb 3, 2016, at 3:00 PM, Félix Cloutier <felixcca at yahoo.ca <mailto:felixcca at yahoo.ca>> wrote:
>>> 
>>> Thanks. I have updated the proposal to reflect this.
>>> 
>>> One thing that remains unspecified is the behavior when the closure throws. Feedback and opinions would be very welcome here.
>>> 
>>> Some alternatives that I can think of:
>>> 
>>> disallow throwing from @noescape(once) closures;
>> 
>> I’d strongly prefer this.  Once/if the base proposal is accepted and implemented, we can always expand from there if strong motivation exists for doing so.
>> 
>> -Chris
> 
> Previously I had thought of the try? and try! but even with plain try the compiler might not know if a variable is initialized or not if the @noescape(once) must not run on throws
> 
> let foo: Int
> do {
>     try withLock(someLock, timeout: 0.5) {
>         foo = sharedThing.foo
>     }
>     // immutable foo can be read not written to
> } catch {
>     print("couldn't acquire lock fast enough")
> }
> // is immutable foo initialized or not, must prevent both reads and writes
> 
> So will the compiler be able to properly handle this ambiguity?

I believe so, but I can’t say with 100% certainty without diving into some more details.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160203/7c55e934/attachment.html>