[swift-evolution] [Pitch] Importing Objective-C 'id' as Swift 'Any'

[Kevin Lundberg]

+1, as long as the weird dynamic @objc method lookup behavior on
AnyObject isn't also carried over to Any as part of this proposal.  This
behavior is a source of frustration for me as it reduces how much I can
reason about code i work with when it creeps in unknowingly, and I don't
even like properties being exposed (which option 3 suggests), since
that's where I see it come up most often day to day. I'd personally like
to see it go away completely.

I brought this up on the list a few months ago but I ended up not being
able to pursue a proposal at the time. However, my idea was that if we
need to keep dynamic lookup around, a dedicated protocol could have this
behavior applied to it, so that API consumers who need it could
explicitly opt into using the dynamic method lookup:

@objc protocol ObjcObject {} // defined in the stdlib/overlay/wherever
it makes the most sense

(Foo.foo() as ObjcObject).someDynamicallyDiscoveredMethod()

This has the added benefit of notifying readers of the code that it
isn't portable, since the type of the value is made explicit as one that
only is allowed in obj-c. Would this be a satisfactory solution to the
problem if this behavior needs to stay in place?

- Kevin

On 7/1/2016 7:37 PM, Joe Groff via swift-evolution wrote:
> Hi everyone. After implementing SE-0072, disabling the implicit bridging conversions from Swift value types to classes (https://github.com/apple/swift-evolution/blob/master/proposals/0072-eliminate-implicit-bridging-conversions.md), we immediately observed a severe negative impact on Cocoa interop as our users at Apple adapted to the change, forcing us to roll it back. `id`-based interfaces are still all over the place in the Cocoa SDKs, but it's our goal that Swift programmers should be able to use the value type versions of things without being constantly confronted with marshalling in and out of their `NS` versions, and this change failed that test for Cocoa users. Furthermore, the Foundation corelibs team is interested in continuing to adopt more value types and improving the experience of using Foundation from Swift without being hamstrung by the limitations of ObjC interop. We can address the problem of value-type-to-id interfacing in a different way—instead of making it a special case in the type system, we can handle it in the Objective-C bridge instead, by bridging Objective-C's `id` type to `Any` instead of `AnyObject`. This is a big change, but I think it leads to an overall Swiftier and more flexible model. I'm working on a proposal to this effect and would like to start getting feedback on it. Thanks for taking a look!
>
> https://github.com/jckarter/swift-evolution/blob/1316004246e45296f81582477d70c22f95ec106c/proposals/XXXX-id-as-any.md
>
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution