Responses inline! Sincerely, Zachary Waldowski [email protected]
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 > [email protected] > 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? _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
