[swift-evolution] Guaranteed closure execution

[Dennis Lysenko]

Just curious, is there a deeper-than-semantic difference between a
@noescape(once) closure and an inlined closure?

On Sun, Apr 24, 2016, 5:58 PM Chris Lattner via swift-evolution <
swift-evolution at swift.org> wrote:

> On Apr 23, 2016, at 3:18 AM, Gwendal Roué via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Hello Andrew,
>
> I'm rather embarrassed: the initial design of this proposal was based on a
> modifier of @noescape:
>
> func f(@noescape(once) closure: () -> ()) { … }
>
> But since the 0049 proposal has been accepted (
> https://github.com/apple/swift-evolution/blob/master/proposals/0049-noescape-autoclosure-type-attrs.md),
> @noescape is no longer an argument qualifier, but a type attribute.
>
> The `once` discussed here can not be part of the type: if noescape can
> understandably be part of the type, the fact that a function guarantees it
> will call a closure once is a quality of that function, not of the closure.
>
> So the proposed @noescape(once) syntax is now confusing as it would mix a
> type attribute and a argument qualifier.
>
> I don't quite know how to escape this:
>
> // two @ signs
> func f(@noescape @once closure: () -> ()) { … }
>
> // Implies @noescape
> func f(@once closure: () -> ()) { … }
>
> I'd like advice from competent people before I would attempt a rewrite of
> the proposal.
>
>
> Hi Gwendal,
>
> I don’t think that the movement of @noescape affects the approach: I’d
> suggest that a proposal (e.g. Felix’s) go with:
>
> func f(closure: @noescape(once) () -> ()) { … }
>
> The semantics are clear: the closure is guaranteed to be called exactly
> once on all normal and “throw” paths.  Paths that do not return in either
> of those ways (e.g. a call to abort) do not need to call the closure.
>
> IMO, this is a small scope proposal that is likely to be accepted.
>
> -Chris
>
>
>
> Gwendal Roué
>
> Le 10 avr. 2016 à 23:26, Andrew Bennett <cacoyi at gmail.com> a écrit :
>
> Sorry I missed that scrolling back through the history, that proposal
> looks great. It doesn't look like it has been submitted as a pull request
> to swift-evolution yet though.
>
> On Sunday, 10 April 2016, Gwendal Roué <gwendal.roue at gmail.com> wrote:
>
>> Felix Cloutier already wrote one:
>> https://github.com/zneak/swift-evolution/blob/master/proposals/00xx-noescape-once.md
>>
>> Do you think it needs to be rewritten?
>>
>> Gwendal Roué
>>
>> Le 10 avr. 2016 à 14:56, Andrew Bennett <cacoyi at gmail.com> a écrit :
>>
>> Hi, not beyond this thread that I have seen. I think it's worth you
>> summarizing this thread in a formal proposal and putting it up for
>> discussion or submitting it as a PR :)
>>
>> On Sunday, 10 April 2016, Gwendal Roué <swift-evolution at swift.org> wrote:
>>
>>> Hello all,
>>>
>>> I was wondering if this topic had evolved in anyway since its original
>>> introduction.
>>>
>>> @noescape(once) would still be a useful addition to the language!
>>>
>>> Gwendal Roué
>>>
>>>
>>>
>>> Le 3 févr. 2016 à 22:21, Félix Cloutier via swift-evolution <
>>> swift-evolution at swift.org> a écrit :
>>>
>>> I updated the proposal to address some concerns. It can be found at:
>>> https://github.com/zneak/swift-evolution/blob/master/proposals/00xx-noescape-once.md
>>>
>>> Things that changed:
>>>
>>>
>>>    - It now says that the closure must be called on code paths where
>>>    the function throws;
>>>    - you can have multiple @noescape(once) parameters but they can't
>>>    make assumptions from one another.
>>>
>>>
>>> I'm not 100% convinced that forcing a call on code paths that throw is
>>> always desirable. I've changed it because Chris's support probably means
>>> that the feature has better chances of making it, but I'm not convinced
>>> yet. If throwing allows me to return without calling the closure, I can
>>> write this:
>>>
>>> do {
>>> let foo: Int
>>> try withLock(someLock, timeout: 0.5) {
>>> foo = sharedThing.foo
>>> }
>>> } catch {
>>> print("couldn't acquire lock fast enough")
>>> }
>>>
>>> which would be kind of messy if instead, the closure needed a parameter
>>> to tell whether the lock was acquired or not when it runs.
>>>
>>> Félix
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160425/6c25c1b5/attachment.html>