[swift-evolution] [Review] SE-0057: Importing Objective-C Lightweight Generics

[Douglas Gregor]

> On Mar 31, 2016, at 11:42 AM, Zach Waldowski via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Responses inline!
> 
> Sincerely,
>   Zachary Waldowski
>   zach at waldowski.me
> 
> On Thu, Mar 31, 2016, at 02:11 PM, Chris Lattner via swift-evolution
> wrote:
>> 	* What is your evaluation of the proposal?
> 
> The strongest of +1's. It will allow much greater flexibility for the
> bridge, both in our own code and Apple's frameworks.
> 
>> 	* Is the problem being addressed significant enough to warrant a change to Swift?
> 
> Yes. Like SE-0055, it's mildly ironic that these new features can
> occasionally be more expressive or compiler-checked by Clang than by
> Swift.
> 
>> 	* Does this proposal fit well with the feel and direction of Swift?
> 
> At the high-level, absolutely. More generics = safer and smarter code.
> 
> At the lower-level, I'm somewhat concerned about the mismatch between
> the Swift side of lightweight generics vs. honest-to-god Swift generics.
> As an instructor, I worry that the limitations may make learning
> generics even more hairy. Considering "Restrictions on uses of
> Objective-C parameterized classes" (while all the restrictions
> completely make sense), I wonder how difficult it'll be to explain why
> in a given specific instance (i.e., pulling a value out of a [String:
> AnyObject]) can't be casted.

I agree that the restrictions will feel arbitrary, because it takes a fairly deep understanding of the implementation models of both ObjC generics and Swift generics to understand why they are there. My hope is that imported ObjC generic classes will be used far more than they are extended.

> _
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> A couple of questions, since this proposal hasn't had the regular
> Evolution run-through:

It did get some discussion at

	http://thread.gmane.org/gmane.comp.lang.swift.evolution/2886

> 1. The section "Importing unspecialized types" makes reference to
> defaulting to the unbound requirement when something isn't annotated in
> Objective-C. This is notably something that isn't true in Swift at
> present (i.e., a T: ErrorType can't be satisfied by ErrorType). Would
> this be a change that comes generalized to Swift, or is just true of the
> lightweight generics bridge.

@objc protocols don’t have associated types or self requirements, and (from an implementation standpoint) a object of @objc protocol type isn’t actually any different from an object of some class type that conforms to the @objc protocol.

> 
> 2. How undefined is the undefined behavior in things coming from
> Objective-C? If something is exposed into Swift as one type bounds, but
> for legacy or bug reasons, another class is pushed across the bridge,
> precisely what color will the resulting explosion be at runtime?

It’s truly undefined behavior. For example, if it’s a Swift-defined class we’re expecting but we get an object of some unrelated type in its place, we might very well poke directly at storage in the object (i.e., when accessing a stored property), or grab a random pointer out of the vtable that isn’t what we expected.

> 
> 3. Re: "Opting in to type argument discovery", how would initialization
> look for GKComponentSystem? Having to do
> GKComponentSystem<SomeType>(componentClass: SomeType.self) would be
> pretty onerous.

That onerous solution is what one gets from this proposal.

> Would this have to be treated in the overlay framework
> too as well?


One would have to clean this up in the overlay.

	- Doug