Requiring blocks (universally)


(Saleem Abdulrasool) #1

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.

···

--
Saleem Abdulrasool
compnerd (at) compnerd (dot) org


(Joe Groff) #2

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.

-Joe

···

On Jun 24, 2016, at 11:05 AM, Saleem Abdulrasool via swift-dev <swift-dev@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.


(Slava Pestov) #3

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

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!

···

On Jun 24, 2016, at 11:23 AM, Joe Groff via swift-dev <swift-dev@swift.org> wrote:

On Jun 24, 2016, at 11:05 AM, Saleem Abdulrasool via swift-dev <swift-dev@swift.org> wrote:

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