Just curious, is there a deeper-than-semantic difference between a @noescape(once) closure and an inlined closure?
On Sun, Apr 24, 2016, 5:58 PM Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > On Apr 23, 2016, at 3:18 AM, Gwendal Roué via swift-evolution < > swift-evolution@swift.org> 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. > > > 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 <cac...@gmail.com> 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é <gwendal.r...@gmail.com> 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 <cac...@gmail.com> 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é <swift-evolution@swift.org> 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 < >>> swift-evolution@swift.org> 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 >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> >>> >> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution