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

[Russ Bishop]

> On Mar 24, 2016, at 1:26 PM, Chris Lattner <clattner at apple.com> wrote:
> 
> 
>> On Mar 24, 2016, at 11:57 AM, Russ Bishop via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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.
>> 
>> 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

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