[swift-evolution] Guaranteed closure execution

[Matthew Johnson]

> On Feb 1, 2016, at 3:59 PM, Chris Lattner <clattner at apple.com> wrote:
> 
>> 
>> On Feb 1, 2016, at 1:43 PM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>> 
>> 
>>> On Feb 1, 2016, at 3:25 PM, Chris Lattner <clattner at apple.com <mailto: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.
> 
> You’re right, the caller could enforce this, so it does provide marginal value beyond a comment.  I think the rest of my point stands though.

Sure, I think it’s a somewhat subjective judgement call.  

I prefer to get as many guarantees as possible from the compiler.  In cases where the semantics are likely to be documented in a comment, assumed or implicit I would prefer to see them expressed directly in the language.

I understand the case that it is simpler to leave it in a comment, I just have a different preference.  

There have been other topics where a similar tradeoff / judgement call is relevant, such as the `local` access control proposal.  

My sense so far is that Swift tries to strike a middle path, introducing annotations where the perceived benefit passes a test of being significant enough (such as the @noescape annotation and likely the once modifier).  It seems like in *most* cases a mere semantic guarantee by the compiler isn’t considered to be benefit enough to pass that test - optimization potential and / or a new capability (such as the ability to initialize values).  

-Matthew

> 
> -Chris

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