<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 25, 2016, at 3:34 PM, David P Grove via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><p class="">Currently on Linux, the various libdispatch types (dispatch_object_t, dispatch_queue_t, etc.) are imported into Swift as COpaquePointer on Linux. This causes a number of problems including:<br class=""> (a) The intended subtyping relationships are lost, resulting in some of the dispatch APIs not being usable (<a href="https://bugs.swift.org/browse/SR-737" class="">https://bugs.swift.org/browse/SR-737</a>)<br class=""> (b) The libdispatch types can't be used in Swift where AnyObject is expected (<a href="https://bugs.swift.org/browse/SR-740" class="">https://bugs.swift.org/browse/SR-740</a>)<br class=""> (c) In Swift code that manipulates values coming from libdispatch, the expected retain/release operations are not generated by the compiler on Linux.<br class=""><br class="">I can see two obvious ways to tackle these issues (and perhaps other problems with the same root cause I haven't encountered yet). <br class=""> (1) Stay with the current C-level code of libdispatch where dispatch_object_t et al. simulate enough of the Objective-C object model that they can masquerade as Objective-C objects. Convince the Swift compiler to import them as Objective-C types on Linux even though there is not an Objective-C runtime (just the stubbed out bits of it that are in libdispatch).<br class=""> (2) Change the current C-level code of libdispatch so that on Linux dispatch_object_t et al. simulate/implement enough of the Swift object model that they can masquerade as Swift objects. Convince the Swift compiler to import them as Swift types.<br class=""><br class="">My gut is that (2) is the more desirable path to pursue. The main downside I see is that it will likely make libdispatch.so dependent on libswiftCore.so (to avoid replicating object model implementation functions). <br class=""><br class="">Before seriously starting down either path, I'd like to get some guidance on what experts think the desired outcome should be and if I've overlooked a better option.<br class=""></p></div></div></blockquote></div><div class="">I agree that (2) is preferable; it'd be great if the entire corelibs platform could avoid needing to support multiple object models. You'll probably also have problems with blocks, which also aren't Swift-refcountable. We might be able to also customize the blocks runtime to use Swift refcounting as well. There's some trickiness there since global and stack blocks are ABI emitted by Clang, so swift-clang would need changes to match.</div><div class=""><br class=""></div><div class="">-Joe</div></body></html>