[swift-evolution] [swift-corelibs-dev] Proposal: add `noescape` attribute to public API (particularly libdispatch)

[Pierre Habouzit]

> 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 also pointed out dispatch_once(), which even it doesn’t make sense for swift where the globals already have the proper semantics, is still useful as the compiler can still implement various optimizations in how the block captures its variables (it is okay to use the things where they are on the stack as opposed to have to create a real state for the block).

> 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.
> 
> Thoughts?
> 
> 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
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151205/b39520e4/attachment.html>