> On Sep 28, 2016, at 3:18 AM, Adrian Zubarev via swift-evolution > <[email protected]> wrote: > > func unsafeBitCast<T, U>(_: T, to type: Type<U>) -> U > func ==(t0: Subtype<Any>?, t1: Subtype<Any>?) -> Bool > func type<T>(of: T) -> Subtype<T> // SE-0096 > That last example, type(of:), is rather interesting, because it is actually a > magic syntax rather than a function. We propose to align this syntax with > Type and Subtype by renaming it to Subtype(of:). We believe this is clearer > about both the type and meaning of the operation. > Why would we not have type(of:) and subtype(of:)? Why would I want the Subtype<T> instead of the specific Type<T>?
What is the rationale for losing the meta type relationships by having Type<U> not be a subtype of Type<T>? > let anInstance: NSObject = NSString() > let aClass: Subtype<NSObject> = Subtype(of: anInstance) > > print(aClass) // => NSString > More details: > > Every static or class member of T which can be called on all subtypes is an > instance member of Subtype<T>. That includes: > > Static/class properties and methods > > Required initializers (as methods named init) > > Unbound instance methods > > The Type<T> of a concrete type T has all of the members required by > Subtype<T>, plus non-required initializers. > > The Type<T> of a protocol T includes only unbound instance methods of T. > > If T conforms to P, then Subtype<T> is a subtype of Subtype<P>, even if T is > a protocol. > > The type of Subtype<T>.self is Type<Subtype<T>>. > > The type of Type<T>.self is Type<Type<T>>, which is not a subtype of any type > except Subtype<Type<T>>. There is an infinite regress of Type<...<Type<T>>>s. > > Subtypes are abstract types similar to class-bound protocols; they, too, > support identity operations. > > Types are concrete reference types which have identities just like objects do. > > swift Int.self === Int.self // true Int.self === Any.self // false > > > Some examples > I don’t see C defined in the example. > Impact on existing code > > This is a source-breaking change that can be automated by a migrator. > > We suggest the following migration process; this can differ from the final > migration process implemented by the core team if this proposal will be > accepted: > To the extent possible I suggest that Swift 4+ stick to deprecations unless it presents a significant effort. I think a lot of people are a bit exhausted with huge syntax changes and the impression was that most source-breaking changes were being done in Swift 3 so we could do them once. > Alternatives considered > > Other names for Type and Subtype were considered: > > Type: SpecificType, Metatype or ExactType. > Subtype: Supertype, Base, BaseType, ExistentialType or TypeProtocol. > Alternatively the pseudo initializer Subtype(of:) could remain as a global > function: > > public func subtype<T>(of instance: T) -> Subtype<T> > -- > Adrian Zubarev > Sent with Airmail I think there is some potential for confusion with Subtype<T>, but I don’t want to bike shed it too much :) Overall looks really nice! Russ
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
