> * 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
