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é <[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), > @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]> 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]> 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]> 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
