> On Mar 24, 2016, at 10:26 AM, Alex Martini via swift-evolution
> <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.
> 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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
