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]> 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] > <javascript:_e(%7B%7D,'cvml','[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] > <javascript:_e(%7B%7D,'cvml','[email protected]');> > https://lists.swift.org/mailman/listinfo/swift-evolution > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
