[swift-evolution] Guaranteed closure execution

[Matthew Johnson]

> On Feb 1, 2016, at 2:46 PM, Chris Lattner <clattner at apple.com> wrote:
> 
> On Feb 1, 2016, at 6:31 AM, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> func foo() {
>>>> 	let bar: Int
>>>> 	withNoEscape { bar = 1 }
>>>> }
>>>> 
>>>> func withNoEscape(@autoclosure(once) closure: () -> ()) { /* snip */ }
>>> 
>>> 
>>> Looking back, I do think that there should be a way to exit from `withNoEscape` without calling the closure, so yes, throwing should imply that the closure wasn't executed. If it's possible that `foo` swallowed an error from a throwing `withNoEscape`, the compiler should assume that the variables within haven't been initialized:
>> 
>> I’m glad to see an @autoclosure func in this thread.  We will want to be able to use this feature with @autoclosure in addition to @noescape.
>> 
>> As far as exiting without calling the closure, I suggest `@noescape(once?)`.  The `?` indicates the closure may or may not be called, but will not be called more than once.
> 
> I don’t see how this is useful.  You wouldn’t be able to initialize a value with this semantic, so it isn’t any more powerful than @noescape on the caller side.

Right, you would not be able to use it for initialization.

It gives a guarantee that the closure will not be executed twice.  This semantic guarantee could be useful, especially if the closure has side-effects.  It adds the clarity of a guarantee  to APIs where the zero-or-one-times semantic is implicit with @noescape alone.

-Matthew 
 
> 
> -Chris

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