[swift-evolution] Guaranteed closure execution

Matthew Johnson matthew at anandabits.com
Mon Feb 1 15:43:29 CST 2016

> On Feb 1, 2016, at 3:25 PM, Chris Lattner <clattner at apple.com> wrote:
> On Feb 1, 2016, at 1:02 PM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>>>> 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.
> Right, but unless the compiler is going to enforce it somehow, it doesn’t add any value above a comment.  Particularly given that we want to keep the language simple where possible, I think that a comment would be perfectly fine for this.  We don’t want to be in the business of providing a "documentation hook” in the language for every theoretical invariant someone might want to express.

I agree if the compiler isn’t going to enforce it.  The value is in the guarantee.  

Why wouldn’t the compiler enforce it in this case?  Is it hard to implement?  It doesn’t seem like it should be any harder than guaranteeing exactly once.

> -Chris

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

More information about the swift-evolution mailing list