[swift-evolution] [Pitch] Refactor Metatypes

[Russ Bishop]

> On Sep 28, 2016, at 3:18 AM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160929/27d41bbc/attachment.html>