[swift-dev] Requiring blocks (universally)

[Slava Pestov]

> On Jun 24, 2016, at 11:23 AM, Joe Groff via swift-dev <swift-dev at swift.org> wrote:
> 
> 
>> On Jun 24, 2016, at 11:05 AM, Saleem Abdulrasool via swift-dev <swift-dev at swift.org> wrote:
>> 
>> Hi,
>> 
>> The blocks runtime itself is pretty tiny, and works across various targets already, so including it is not too onerous.  As such, Id like to propose enabling blocks across all the targets.
>> 
>> This make it easier to then import code on targets which have optional blocks support.  For most users, this would be a transparent change, but would mean that the clang importer goes through a more similar path across the various targets.
> 
> It's a little trickier than that. We only support Swift refcounting object headers on non-Darwin platforms, since there's no universal objc_retain implementation to fall back to. Blocks don't use Swift-compatible refcounting with the current runtime.

It’s a bit more subtle than that. I think IRGen now does the right thing if a value is statically known to be a block, emitting calls to the block-specific refcounting entry points on both platforms:

https://github.com/apple/swift/commit/aa40f206cb993846c3c211219e54ec246a62a384 <https://github.com/apple/swift/commit/aa40f206cb993846c3c211219e54ec246a62a384>

However, on Darwin we can cast a block to AnyObject, and use the unknown reference counting entry points on these values. On Linux, AnyObject still uses Swift-native reference counting, and thus is not bitwise-compatible with blocks. So as long as this is not an issue, you can go ahead and use blocks on Linux.

We’ve talked about hacking the blocks runtime to use Swift reference counting on Linux, but this is a non-trivial change.

Saleem, please give it a shot and let us know if you run into any problems!

> 
> -Joe
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160624/60010bbb/attachment.html>