> On Mar 24, 2016, at 1:26 PM, Chris Lattner <clatt...@apple.com> wrote: > > >> On Mar 24, 2016, at 11:57 AM, Russ Bishop via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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. >> >> I would like to unify this to either have the initializers or have the >> static functions but not both, but I don’t know which is preferred from an >> implementation perspective. The initializers feel more “Swifty” but moving >> back to static functions is perfectly workable. > > The preference was to just have the initializers, since that is the preferred > way to express conversions.
Sounds good to me; I updated the proposal to use initializers. Russ
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
