[swift-corelibs-dev] Proposal: add `noescape` attribute to public API (particularly libdispatch)
anthony.parker at apple.com
Sat Dec 5 15:40:17 CST 2015
Thanks for bringing the discussion on this topic here.
One topic I wanted to discuss was finding a comprehensive list of API that needs the attribute. The next step after that is figuring out how to get this attribute to be consistent across Darwin and Swift open source.
One option was to use the API notes feature of the compiler to annotate these APIs as part of the import into Swift. Another is to get the C headers changed (on Darwin too) to add the attribute. We may want to do one approach in the short term and another in the long term.
> On Dec 5, 2015, at 12:53 PM, Jacob Bandes-Storch via swift-corelibs-dev <swift-corelibs-dev at swift.org> wrote:
> There are several functions in public API, such as dispatch_sync and dispatch_apply, which do not allow their block parameters to escape the function call.
> However, they are not currently exposed to Swift as @noescape, meaning that users are required to specify "self." or "[weak self]" in their closures.
> The instances I can think of:
> - dispatch_sync
> - dispatch_barrier_sync
> - dispatch_apply
> - dispatch_block_perform (thanks to Pierre Habouzit for pointing this out)
> I provided a preliminary implementation at https://github.com/apple/swift-corelibs-libdispatch/pull/6 <https://github.com/apple/swift-corelibs-libdispatch/pull/6>, but it needs refinement. Tony Parker mentioned commented that there might be similar changes to make for the swift-corelibs-foundation project.
> Question: does __attribute__((noescape)) have the same meaning when applied to C function pointers? Namely, does Swift understand @noescape as it applies to @convention(c)?
> Jacob Bandes-Storch
> swift-corelibs-dev mailing list
> swift-corelibs-dev at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-corelibs-dev