on Wed May 25 2016, Joe Groff <jgroff-AT-apple.com> wrote: >> On May 25, 2016, at 12:28 PM, Dave Abrahams <[email protected]> wrote: >> >> >> on Wed May 25 2016, Joe Groff <jgroff-AT-apple.com> wrote: >> > >>>> 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. >> >> Can't we detect in the runtime library that we've got an existential and >> do the right thing? > > Not within the constraints of the type system. P.Protocol and P.Type > are different types, and the former isn't a model of the latter (since > P has no methods of its own so can't satisfy P's static requirements).
I mean at runtime, in C++ code. -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
