[swift-dev] How should NSArray<void(^)(void)>* be imported?
jtbandes at gmail.com
Thu Mar 3 12:26:19 CST 2016
Is another hack the way to go, or should it be correctly imported as
[@convention(block) () -> ()] (which I think would be
On Thu, Mar 3, 2016 at 9:08 AM, Joe Groff <jgroff at apple.com> wrote:
> 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:
> 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
> 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
> 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.
> There's a hack to handle NSArray<Class> * bridging to [AnyObject.Type],
> which has similar problems. Look around for _BridgeableMetatype.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-dev