[swift-evolution] [Idea] Further directions for id-as-Any

[Will Field-Thompson]

This might be useful for some cases, but I have some concerns about tying
serialization to this. I would rather see a Swift-centric rethinking of
serialization than having the runtime dynamically register Objective-C
classes anytime I want to serialize something. Plus, that seems like it's
leaving Linux users out in the cold for serialization — although I'm
primarily a macOS/iOS user, so maybe there's something I don't know about
the corelibs Foundation implementation.

Will Field-Thompson

On Tue, Sep 6, 2016 at 8:20 AM Brent Royal-Gordon via swift-evolution <
swift-evolution at swift.org> wrote:

> In the current Swift 3 betas, value types can now be passed into
> Objective-C as opaque box objects. A couple of reviews are currently
> running which tweak this bridging, exposing Optionals and
> NSValue/NSNumber-compatible types in more natural ways. These are all Good
> Things. I'd like to look ahead and sketch out a way this feature could
> evolve further. This will not be detailed, and much or all of it may be out
> of scope for Phase 1.
>
>
> Firstly, I think we could make boxed value types much more usable from
> Objective-C:
>
> 1. We could bridge selector calls to equivalent Swift methods, where those
> methods are Objective-C-compatible (other than being on a value type). This
> could actually be done dynamically if enough metadata is available.
>
> 2. We could generate a separate subclass of our box class for each bridged
> Swift type. This could actually *still* be done dynamically, I believe.
>
> 3. We could permit value types to conform to @objc protocols. This would
> open up several nice features to us; perhaps most importantly, a value type
> could conform to NSCoding and thereby participate in Foundation's
> serialization mechanisms. I suspect that at this point, the box subclasses
> would have to become "real", i.e., registered at load time. (Perhaps
> they're only greedily registered if they have an explicit @objc?)
>
> 4. We could explicitly declare the bridged methods, properties, and
> conformances in the generated -Swift.h file, thereby making Swift value
> types directly available to Objective-C, where they can be allocated,
> accessed, and manipulated in boxed form.
>
>
> Secondly—and separately, but relatedly—I believe a few simple changes
> could liberalize the @objc-compatibility rules, permitting many more
> members to be exposed to Objective-C:
>
> 1. We could run "omit needless words" in reverse when exposing Swift
> methods to Objective-C. This would prevent overloads from clashing in
> Objective-C, and would also have the bonus feature of producing more
> idiomatic Objective-C interfaces. (Incidentally, is a change considered
> source-breaking if it breaks Objective-C code, not Swift code?)
>
> 2. We could grant access to members using Swift-only type features by
> allowing the Objective-C versions to have looser types than the Swift
> versions, and dynamically enforcing the missing constraints instead. For
> instance, a member with a complicated `where` clause might omit the clause
> in its Objective-C declaration, but enforce it with a dynamic test.
>
> 3. I suspect it might be possible to expose generic types to Objective-C
> with some custom class methods. For instance, a Swift type with `Key` and
> `Value` type parameters might have `+classWithKey:(Class)keyClass
> value:(Class)valueClass` and +`allocWithKey:(Class)keyClass
> value:(Class)valueClass` methods on it.
>
>
> Are these potential features of interest? If so, to what extent do they
> affect binary compatibility? On the one hand, they are extensions, adding
> transparency to things which are currently opaque. But on the other hand,
> they will presumably involve generating type metadata.
>
> --
> Brent Royal-Gordon
> Architechies
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160906/6e330f52/attachment.html>