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

[Russ Bishop]

> On Mar 24, 2016, at 10:26 AM, Alex Martini via swift-evolution <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.

> This doesn’t break the ability of the optimizer to reason about what a dynamic cast can do. We require that the bridgeable conformance must be in the same module as where the type is defined, and we have a white list of things that don’t follow that. Ok... but do we want people to expand casting this way? If we say no, we should take it away from array and string and dictionary too.
> 
> You shouldn’t need implicit conversions — the use case is very narrow, and we would rather have things use explicit conversions. The APIs come in with the right type; the implementation of the bridged type has to do conversion, but its clients don’t have to see that. From the Swift point of view, there won’t be any APIs that take the reference type.
> 
> 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)"


What is the team’s general approach to a situation like this? I feel like the casting discussion is a separate one but it does have an impact on the static function vs initializer discussion. 

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