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 <[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
