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

[Zach Waldowski]

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.

> 	* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I've used type-erased generics before in other languages. While not
preferable when you have something like Swift's implementation, this is
acceptable for a bridge.

> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I've been considering the effects of this feature since bridging came to
ObjC, really excited to see it. Quick glance at the proposal itself.

> 
> _______________________________________________
> 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:

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.

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?

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. Would this have to be treated in the overlay framework
too as well?