[swift-dev] How should NSArray<void(^)(void)>* be imported?

[Joe Groff]

> On Mar 3, 2016, at 2:23 AM, Jacob Bandes-Storch via swift-dev <swift-dev at swift.org> wrote:
> 
> I'm interested in fixing a pet peeve of mine: https://bugs.swift.org/browse/SR-772 <https://bugs.swift.org/browse/SR-772>
> 
> The failing assertion is in Array._forceBridgeFromObjectiveC, namely Swift._isBridgedToObjectiveC(Element.self). Element is plain ol "() -> ()", but probably should be @convention(block) since it was imported from void(^)(void).
> 
> I've started tracing through the importer, and I found that `adjustTypeForConcreteImport` is enforcing FunctionTypeRepresentation::Swift because the ImportKind is BridgedValue — this is hardcoded in the call to importType for the type parameters to NSArray (and NSDictionary and NSSet) in SwiftTypeConverter::VisitObjCObjectPointerType.
> 
> Are the Foundation collection classes only temporarily special-cased here, until Obj-C generics are generally supported? Is someone working on this in the near future?
> 
> If this worked correctly, would we expect to see "var executionBlocks: [@convention(block) () -> ()]" ? If so, would this be best achieved by passing a different ImportKind, possibly introducing a new ImportKind, or some other solution?
> 
> I'm guessing that it doesn't make sense for () -> () to be _ObjectiveCBridgeable, but either way I'm not sure where the _isBridgedToObjectiveC implementation for blocks would come from.
> 
> Bumblingly,
> Jacob

There's a hack to handle NSArray<Class> * bridging to [AnyObject.Type], which has similar problems. Look around for _BridgeableMetatype.

-Joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160303/04843aff/attachment.html>