First off, I agree with Nevin (up-thread) that this is a much clearer version 
of the previous proposal, well done.

> On Sep 28, 2016, at 6:18 AM, Adrian Zubarev via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> Formatted version: 
> https://github.com/DevAndArtist/swift-evolution/blob/refactor_metatypes/proposals/0126-refactor-metatypes.md
>  
> <https://github.com/DevAndArtist/swift-evolution/blob/refactor_metatypes/proposals/0126-refactor-metatypes.md>
> Refactor Metatypes
> 
> Proposal: SE–0126 
> <x-msg://5/0126-refactor-metatypes-repurpose-t-dot-self-and-mirror.md>
> Authors: Adrian Zubarev <https://github.com/DevAndArtist>, Anton Zhilin 
> <https://github.com/Anton3>, Brent Royal-Gordon <https://github.com/brentdax>
> Status: Revision
> Review manager: Chris Lattner <http://github.com/lattner>
> Revision: 2
> Previous Revisions: 1 
> <https://github.com/apple/swift-evolution/blob/83707b0879c83dcde778f8163f5768212736fdc2/proposals/0126-refactor-metatypes-repurpose-t-dot-self-and-mirror.md>
> Introduction
> 
> This proposal removes .Type and .Protocol in favor of two generic-style 
> syntaxes and aligns global type(of:) function (SE–0096) to match the changes.
> 
> Swift-evolution thread (post Swift 3): 
> 
> [Pitch] Refactor Metatypes 
> <applewebdata://A0AAC176-7F99-483F-BC96-BDA55910F1A4>
> Older swift-evolution threads: [1] 
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/025115.html>,
>  [2] 
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/024772.html>,
>  [3] 
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160704/023818.html>
> Motivation
> 
> Every type T has an instance, accessible through T.self, which represents the 
> type itself. Like all instances in Swift, this “type instance” itself has a 
> type, which is referred to as its “metatype”. The metatype of T is written 
> T.Type. The instance members of the metatype are the same as the static or 
> class members of the type.
> 
> Metatypes have subtype relationships which reflect the types they represent. 
> For instance, given these types:
> 
> protocol Proto {}
> class Base {}
> class Derived: Base, Proto {}
> Derived.Type is a subtype of both Base.Type and Proto.Type (and Any.Type). 
> That means that Derived.self can be used anywhere a Derived.Type, Base.Type, 
> Proto.Type, or Any.Type is called for.
> 
> Unfortunately, this simple picture is complicated by protocols. Proto.self is 
> actually of type Proto.Protocol, not type Proto.Type. This is necessary 
> because the protocol does not, and cannot, conform to itself; it requires 
> conforming types to provide static members, but it doesn’t actually provide 
> those members itself. Proto.Type still exists, but it is the supertype of all 
> types conforming to the protocol.
> 
> Making this worse, a generic type always uses T.Type to refer to the type of 
> T.self. So when Proto is bound to a generic parameter P, P.Type is the same 
> as Proto.Protocol.
> 
> This shifting of types is complicated and confusing; we seek to clean up this 
> area.
> 
> We also believe that, in the long term, the dot syntax will prevent us from 
> implementing certain future enhancements that might be valuable:
> 
> Moving the implementation of metatypes at least partly into the standard 
> library.
> Adding members available on all type instances for features like read-write 
> reflection or memory layout information.
> Conforming metatypes to protocols like Hashable or CustomStringConvertible.
> Offering straightforward syntaxes for dynamic features like looking up types 
> by name.
> Proposed solution
> 
> We abolish .Type and .Protocol in favor of two generic-style syntaxes:
> 
> Type<T> is the concrete type of T.self. A Type<T> only ever has one instance, 
> T.self; even if T has a subtype U, Type<U> is not a subtype of Type<T>.
> 
> Subtype<T> is the supertype of all Types whose instances are subtypes of T, 
> including T itself:
> 
> If T is a struct or enum, then Type<T> is the only subtype of Subtype<T>.
> 
> If T is a class, then Type<T> and the Types of all subclasses of T are 
> subtypes of Subtype<T>.
> 
> If T is a protocol, then the Types of all concrete types conforming to T are 
> subtypes of Subtype<T>. Type<T> is not itself a subtype of Subtype<T>, or of 
> any Subtype other than Subtype<Any>.
> 
I’m having trouble reconciling this with rule #2 above, which states that 
“Subtype is the supertype of all Types whose instances are subtypes of T, 
including T itself.” Which one is wrong, or am I confused?

One thing I haven’t understood the motivation for exactly is what someone would 
be able to do with a Proto.self. Dynamic conformance checking? For a concrete 
T, having its .self seems useful for doing dynamic casts and such, but I don’t 
understand why for a Proto you need to have both. You did a good job of 
explaining why T.Protocol and T.Type are different, but not why both of them 
need to exist. So you could definitely do more to spell out the use-cases here.
> Structural types follow the subtype/supertype relationships of their 
> constituent types. For instance:
> 
> Type<(NSString, NSString)> is a subtype of Subtype<(NSObject, NSObject)>
> 
> Metatypes of functions are a little bit more special (the subtyping relation 
> on functions flips around for parameter types 
> <https://en.wikipedia.org/wiki/Covariance_and_contravariance_(computer_science)>):
> 
> Type<(Any) -> Void> is a subtype of Subtype<(Int) -> Void> etc.
> Type<(Void) -> Int> is a subtype of Subtype<(Void) -> Any>

Does this potentially expose contravariant type parameters, and is that an 
issue? (I’m trying to imagine a scenario where you could have an A on the left 
hand side of an arrow and have that leak out to other clients, but I haven’t 
had a chance to write much Swift 3 yet, unfortunately.)
> In this new notation, some of our existing standard library functions would 
> have signatures like:
> 
> 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.
> 
> 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
> 
> 
> Visual metatype relationship example (not a valid Swift code)
> 
> 
> Some examples
> 
> // Types:
> protocol Foo {}
> protocol Boo : Foo {}
> class A : Foo {}
> class B : A, Boo {}
> struct S: Foo {}
> 
> // Metatypes:
> let a1: Type<A> = A.self           //=> Okay
> let p1: Type<Foo> = Foo.self       //=> Okay
> let p2: Type<Boo> = C.self         //=> Error -- `C` is not the same as `Foo`
> 
> let any_1: Subtype<Any> = A.self   //=> Okay
> let any_2: Subtype<Any> = Foo.self //=> Okay
> 
> let a_1: Subtype<A> = A.self       //=> Okay
> let p_1: Subtype<Foo> = A.self     //=> Okay
> let p_2: Subtype<Foo> = Foo.self   //=> Error -- `Type<Foo>` is not a subtype 
> of `Subtype<Foo>`
> 
> // Generic functions:
> func dynamic<T>(subtype: Subtype<Any>, `is` _: Type<T>) -> Bool {
>   return type is Subtype<T>
> }
> 
> func dynamic<T>(subtype: Subtype<Any>, `as` _: Type<T>) -> Subtype<T>? {
>   return type as? Subtype<T>
> }
> 
> let s1: Type<S> = S.self
> 
> dynamic(subtype: s1, is: Foo.self)    //=> true
> dynamic(subtype: s1, as: Foo.self)    //=> an `Optional<Subtype<Foo>>`
> 
> 
> Future Directions
> 
> We could allow extensions on Type and perhaps on Subtype to add members or 
> conform them to protocols. This could allow us to remove some standard 
> library hacks, like the non-Equatable-related == operators for types.
> 
> It may be possible to implement parts of Type as a fairly ordinary final 
> class, moving code from the runtime into the standard library.
> 
> We could offer a Subtype(ofType: Type<T>, named: String) pseudo-initializer 
> which would allow type-safe access to classes by name.
> 
> We could offer other reflection and dynamic features on Type and Subtype.
> 
> We could move the MemoryLayout members into Type (presumably prefixed), 
> removing the rather artificial MemoryLayout enum.
> 
> Along with other generics enhancements, there may be a use for a 
> Subprotocol<T> syntax for any protocol requiring conformance to protocol T.
> 
> 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:
> 
> Any.Type is migrated to Subtype<Any>.
> If T.Type is in function parameter, where T is a generic type parameter, then 
> it’s migrated to Type<T>.
> Every T.Protocol will be replaced with Type<T>.
> Every T.Type in a dynamic cast will be replaced with Subtype<T>.
> If static members are called on a metatype instance, then this instance is 
> migrated to Subtype<T>.
> Return types of functions are migrated to Subtype<T>.
> Variable declarations is migrated to Subtype<T>.
> 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>

Thank you for the hard work you’ve put into this proposal, it’s come a long way!

-Colin

> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> <https://lists.swift.org/mailman/listinfo/swift-evolution>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to