[swift-evolution] Guaranteed closure execution

[Andrew Bennett]

I agree, it would be good if someone like Brent or Chris could chip in.
However, I think that @noescape(once) is still fine.

As long as a @noescape(once) closure must either be passed to a single
function, or called once it seems enforceable.

I don't believe a @noescape closure can be stored, so it doesn't change
anything.


On Sat, Apr 23, 2016 at 8:18 PM, Gwendal Roué <gwendal.roue at gmail.com>
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.
>
> 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
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160423/2bcb7e8f/attachment.html>