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

[Chris Lattner]

> On Mar 24, 2016, at 11:57 AM, Russ Bishop via swift-evolution <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.

>> Implicit conversions. In this proposals, you don’t get implicit conversions. Have a separate discussion about whether we can get rid of the four types that have implicit conversion. We see the existing ones as deeply problematic.
>> 
> The casting was a late addition to allow the user to work around situations where the ObjC API is deficient and to keep the behavior consistent with how other types are bridged. It could be removed if desired but I agree that it should probably be removed from the existing types as well in that case.
> 
> Removing it would unify behavior: conversion happens through initializers, casting through as. That means the example would be more like “let x = SwiftType(SomeObjCType)”. Strings become “let x = String(anNSString)”

Many of us would prefer to reduce the implicit conversions we have today in various ways (e.g. I’m a fan of disabling T -> T? promotion in operator argument contexts, which would solve a number of weird ?? issues).  The existing implicit bridging conversions fall into the same category: it isn’t clear if we can eliminate them, but if we could, that would be great for predictability and for type checker performance.

Upshot of this is that there doesn’t seem to be a reason for this new feature to add new implicit conversions: doing an explicit conversion with “as” seems fine.

-Chris

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