Oh, and I forgot to mention that this would mean deinit would need to extract the block it it hadn't been done already. I would hope (to avoid silent errors) that the compiler would require a reference type with an @once property to have a deinit that checks for a lingering value and deals with it. This would have avoided a few bugs over the years...
-tim > On Apr 23, 2016, at 9:33 AM, Timothy Wood via swift-evolution > <[email protected]> wrote: > > > >> On Apr 23, 2016, at 5:56 AM, Gwendal Roué via swift-evolution >> <[email protected]> > [...] >> >> Since @once actually implies @noescape (as described earlier in the thread), >> it can be shortened to: > [...] > > I'm surprised that @once would imply @noescape. In my opinion this makes it > much less useful. For example, it is common to have asynchronous operations > with a completion handler -- the completion handler will definitely escape > and should definitely get called once. > > In some cases the completion handler may get passed to other functions that > take an @once block, so that should count as passing off your responsibility > to call it. > > In other cases, it may get stored in an object representing a long-lived > async operation. This is trickier, but I would hope that a nullable var > property, only in a reference type, could be marked @once. Reading that > property would return an @once block *and* clear the property (so you'd be > back to needing to call it or pass it away). It is unclear if only closure > properties should be allowed to be marked @once, but presumable the > implementation cloud support any type. > > A simple noescape @once might find a few trivial uses in my codebase, but the > really hard to diagnose bugs have been in async code where escaping is > natural and necessary. > > -tim > _______________________________________________ > 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
