> On May 25, 2016, at 11:42 AM, Erica Sadun <[email protected]> wrote: > > >> On May 25, 2016, at 12:26 PM, Dave Abrahams via swift-evolution >> <[email protected]> wrote: >> I don't understand why the proposal says we can't implement this in the >> library today. >> >> $ swift >> Welcome to Apple Swift version 2.2 (swiftlang-703.0.18.8 clang-703.0.30). >> Type :help for assistance. >> 1> func dynamicType_<T>(_ x: T) -> T.Type { return x.dynamicType } >> 2> dynamicType_(42) >> $R0: Int.Type = Int >> 3> class B {} >> 4. class C : B {} >> 5. dynamicType_(C() as B) >> $R1: B.Type = __lldb_expr_5.C >> 6>
Now try it with a protocol type, or Any: (swift) var x: Any = 1738 // x : Any = 1738 (swift) dynamicType_(x) // r0 : Any.Protocol = protocol<> `dynamicType` is really two operations: For normal concrete types, it produces concrete metatypes, and for existentials, it produces existential metatypes. There's no way to express the latter for an arbitrary unknown protocol type in the language today. -Joe >> IMO exposing it as a special language feature is a mistake unless >> there's something wrong with the implementation above. There are many >> ways we can implement the body of the generic function and still remove >> the .dynamicType property from the language's user model. > > > I'm going to defer to Joe Groff to respond specifically to this. I believe the > issue was that the type signature could not be described in today's Swift > but would be possible in future Swift, as the current type system wouldn't > work for protocol metatypes. > > -- E > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
