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]> 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 <[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 >> >> 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 >> >> >> >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
