[swift-evolution] [Proposal draft] Importing Objective-C Lightweight Generics

Russ Bishop xenadu at gmail.com
Mon Mar 7 23:49:40 CST 2016

+1 on the proposal. Those of us who will be living in a mixed code world for the foreseeable future would make great use of it.

> On Jan 15, 2016, at 9:28 PM, Douglas Gregor via swift-evolution <swift-evolution at swift.org> wrote:
> While the Swift and Objective-C generics systems look similar on the surface, they use fundamentally different semantic models. Specifically, Objective-C lightweight generics are based on type erasure, so we cannot in general recover the type arguments from the metaclass of an Objective-C parameterized class (i.e., because MySet, MySet<NSString *>, and MySet<NSNumber *> all share a metaclass). This leads to several restrictions:
> Downcasting to an instance or metatype of a parameterized Objective-C class is inherently uncheckable, so we place limits on such casts. For example,
I think this is a reasonable restriction. The as! cast is basically what you get in Objective-C anyway (a runtime crash when your promise to the compiler is broken).

> The only major alternative design involves bringing type erasure into the Swift generics system as an alternative implementation. It would lift the restrictions on extensions of parameterized Objective-C classes by treating type parameters in such contexts as the type bounds:
> Doing so could allow the use of "unspecialized" generic types within Swift, e.g., NSMutableArray with no type bounds (possibly spelled NSMutableArray<*>), which would more accurately represent Objective-C semantics in Swift.
> However, doing so comes at the cost of having two incompatible generics models implemented in Swift, which produces both a high conceptual burden as well as a high implementation cost. The proposed solution implies less implementation cost and puts the limitations on what one can express when working with parameterized Objective-C classes without fundamentally changing the Swift model.

Strongly agree that this would be a bad idea.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160307/002a918c/attachment.html>

More information about the swift-evolution mailing list