[swift-evolution] Notes from Swift core team 2016-03-23 design discussion

Alex Martini amartini at apple.com
Thu Mar 24 16:09:03 CDT 2016

> On Mar 24, 2016, at 11:57 AM, Russ Bishop <xenadu at gmail.com> wrote:
>> On Mar 24, 2016, at 10:26 AM, Alex Martini via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote
>> Allow Swift types to provide custom Objective-C representations <file:///Users/alexmartini/DevPubs%20Git%20Repositories/Swift%20Language%20Review/_build/html/LR_MeetingNotes/2016-03-23.html#allow-swift-types-to-provide-custom-objective-c-representations>
>> https://github.com/apple/swift-evolution/pull/198 <https://github.com/apple/swift-evolution/pull/198>
>> The associated type could be AnyObject rather than NSObject. The use case for a non-subclass of NSObject is very narrow, but it’s not a needed restriction.
>> The unconditionalyBridgeFromObjectiveC function can probably go away. Calling initializers from the downcasting infrastructure is horrible. If we need a function, they
> Was there more to this line of thought? It looks like it got cut off.

Sorry, I didn't have anything else here.  It looks like I didn't finish the sentence while typing during the meeting.

If I remember right, the thought was that we can make a function (or maybe a closure) that calls the initializer if the surrounding code needs a function.

— Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160324/26d88ce5/attachment.html>

More information about the swift-evolution mailing list