I see, thanks for the clarification. How is it, then, that properties whose type is void(^)(void) already work fine?<br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 3, 2016 at 12:16 PM Joe Groff <<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On Mar 3, 2016, at 10:26 AM, Jacob Bandes-Storch <<a href="mailto:jtbandes@gmail.com" target="_blank">jtbandes@gmail.com</a>> wrote:</div><br><div><div dir="ltr">Is another hack the way to go, or should it be correctly imported as [@convention(block) () -> ()] (which I think would be _isBridgedToObjectiveC already)?</div></div></blockquote><div><br></div></div></div><div style="word-wrap:break-word"><div><div>Bridging to @convention(block) is probably more practical, since we'd otherwise need to be able to thunk an arbitrary call signature at runtime. However, @convention(block) is still a structural type, so it would need special case handling similar to _BridgeableMetatype to be able to feed a _BridgedToObjectiveC conformance into the runtime.</div></div></div><div style="word-wrap:break-word"><div><div><br></div><div>-Joe</div></div></div><div style="word-wrap:break-word"><div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra">
<br><div class="gmail_quote">On Thu, Mar 3, 2016 at 9:08 AM, Joe Groff <span dir="ltr"><<a href="mailto:jgroff@apple.com" target="_blank">jgroff@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br><div><blockquote type="cite"><div>On Mar 3, 2016, at 2:23 AM, Jacob Bandes-Storch via swift-dev <<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>> wrote:</div><br><div><div dir="ltr"><div>I'm interested in fixing a pet peeve of mine: <a href="https://bugs.swift.org/browse/SR-772" target="_blank">https://bugs.swift.org/browse/SR-772</a></div><div><br></div><div>The failing assertion is in Array._forceBridgeFromObjectiveC, namely <span>Swift._isBridgedToObjectiveC(Element.</span><span>self</span><span>). </span><span>Element is plain ol "() -> ()", but probably should be @convention(block) since it was imported from void(^)(void).</span></div><div><br></div><div>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.</div>
<div><br></div><div>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?</div><div><br></div><div>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?</div><div><br></div><div>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.</div><br clear="all"><div><div><div dir="ltr"><div>Bumblingly,</div><div>Jacob<br></div></div></div></div>
</div></div></blockquote><br></div></div></div><div>There's a hack to handle NSArray<Class> * bridging to [AnyObject.Type], which has similar problems. Look around for _BridgeableMetatype.</div><span><font color="#888888"><div><br></div><div>-Joe</div><br></font></span></div></blockquote></div><br></div></div>
</div></blockquote></div></div></blockquote></div>