> On Apr 23, 2016, at 3:18 AM, Gwendal Roué via swift-evolution
> <[email protected]> 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
>
> <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 <[email protected]
>> <mailto:[email protected]>> 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é <[email protected]
>> <mailto:[email protected]>> wrote:
>> Felix Cloutier already wrote one:
>> https://github.com/zneak/swift-evolution/blob/master/proposals/00xx-noescape-once.md
>>
>> <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 <[email protected]
>>> <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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é <[email protected]
>>> <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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
>>>> <[email protected] <>> 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
>>>>
>>>> <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
>>>> [email protected] <>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>
>>
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
