> On Mar 24, 2016, at 11:57 AM, Russ Bishop <xen...@gmail.com> wrote:
>
>
>> On Mar 24, 2016, at 10:26 AM, Alex Martini via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
