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

[Brent Royal-Gordon]

> 	* What is your evaluation of the proposal?

I like it, but I have a couple of minor issues with the details.

The first is that type discovery does not support the full richness of either language's type system. Both languages allow a type to be either a class or a group of protocols, and Objective-C even allows one class + N protocols. I believe these methods should permit any valid Objective-C generic type to be expressed. That could be achieved by having two methods (plus class method variants):

	- (nullable Class)classForGenericArgumentAtIndex:(NSUInteger)index;	// nil means id
	- (NSArray<Protocol*>*)protocolsForGenericArgumentAtIndex:(NSUInteger)index;

The second is the issue of extensions. Rather than rejecting the use of the generic type parameter, I think we would be better off treating it as though it were a nested typealias. That is, when you write this:

	@interface MySet<__covariant ObjectType: id<NSCopying>> : NSObject

Then MySet.ObjectType is NSCopying. That would allow you to use ObjectType in extensions without particularly caring whether or not you were working with full generics.

The third is that I'm troubled by the invisibility of this feature given its limitations. I understand why you don't want to implement full type erasure, but there should at least be some suggestion of the semantics in the generated headers:

	class MySet<@erased ObjectType: NSCopying>: NSObject

@erased does not have to actually work in user-written code—it's just there in the generated header to mark the type parameter's special semantics.

Finally, this is a severable issue, but I think it's worth mentioning: it would be very helpful to expose generic classes back to Objective-C somehow. One of my projects has a CaseInsensitiveDictionary type written in Swift; I have reference-typed NSObject subclasses to expose it to Objective-C, but these can't be generic. Even lightweight generics, even exposed only to Objective-C, would make this code a lot better.

> 	* Is the problem being addressed significant enough to warrant a change to Swift?

Yes. I've missed this type information in Swift.

> 	* Does this proposal fit well with the feel and direction of Swift?

Yes.

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

Swift's interop concerns are pretty unique, in my experience.

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

Well, I've been drafting this email for several hours. Does that count?

-- 
Brent Royal-Gordon
Architechies