Responses inline!
Sincerely,
Zachary Waldowski
zach@waldowski.me* 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolutionA 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
···
On Mar 31, 2016, at 11:42 AM, Zach Waldowski via swift-evolution <swift-evolution@swift.org> wrote:
On Thu, Mar 31, 2016, at 02:11 PM, Chris Lattner via swift-evolution > wrote: