[swift-evolution] [Revision] [Pitch] Rename `T.Type`

[Adrian Zubarev]

Hello everyone,

recently I was pinged on twitter to a conversation between Jacob Bandes-Storch, Joe Groff and Slava Pestov.

Here is the conversation covering a few more facts about the mysterious .Protocol:

[Jacob Bandes-Storch] Was hoping to just define type<T>(of x: T) -> T.Type and move impl of emitMetatypeOfValue() there.

[Joe Groff] Yeah, that won’t do the right thing for existentials compared to x.dynamicType.

[Jacob Bandes-Storch] When you say “do the right thing” you mean the return type? Shouldn’t type(of x: Proto) -> Proto.Type?

[Slava Pestov] Right, but if T := P, then T.Type is P.Protocol, not P.Type

[Jacob Bandes-Storch] Mind bending… Suppose T : P, x : P = T(), then type(of: x) returns T, and T: P.Type. What am I missing?

[Joe Groff] P.Type is really Any<P.Type>, and P.Protocol is really (Any<P>).Type. If T == Any<P>, T.Type == latter

[Joe Groff] dynamicType is different for existentials: open existential, take opened metatype, erase to e.metatype

[Jacob Bandes-Storch] Now I’m confused by current behavior: GIST … isn’t dynamicType’s job to return T.self?

[Joe Groff] invokes `foo() on the opened type, then re-closes an existential around the result if Self is involved

[Jacob Bandes-Storch] But this does what I’d expect: GIST

[Joe Groff] Right, member lookup also implicitly opens an existential.

[Jacob Bandes-Storch] Point being that there’s no way to do this for generic params?

[Joe Groff] Not in argument position. Only ‘self’ gets this magic behavior.

[Jacob Bandes-Storch] Is that a bug or feature? Seems to me dynamicType should always be able to get the actual runtime type.

[Joe Groff] Consider this situation:

func foo<T>(x:T) -> (T.Type, T.Type) {
   return (T.self, x.dynamicType)
}
[Jacob Bandes-Storch] Still struggling to see what’s wrong with returning “real” type. What can be subst. for `T that breaks it?

[Joe Groff] Consider T == P with x.dynamicType trying to produce the existential dynamic type.

[Jacob Bandes-Storch] I think I’m mostly confused because P.Type vs. P.Protocol is really non-obvious. Has renaming been discussed?

[Joe Groff] The gotcha mainly comes up if you try to replicate the builtin behavior. Most people don’t try to do that.

[Jacob Bandes-Storch] Would it make sense to disallow x.dynamicType in such cases? Gotcha would be less confusing if forced to say `T.self.


-- 
Adrian Zubarev
Sent with Airmail

Am 22. Juli 2016 um 14:47:08, Vladimir.S via swift-evolution (swift-evolution at swift.org) schrieb:

Thank you for the article. Very informative.

So, I believe core team can answer the question : "..why P.Protocol is  
needed" and if we can remove it without problems.


Small fix - A&B should have ': HasStatic' and closing bracket here:

protocol HasStatic { static func staticMethod() }
struct A { static func staticMethod() -> String { return "A" }
struct B { static func staticMethod() -> String { return "B" }


On 22.07.2016 14:40, Anton Zhilin via swift-evolution wrote:
> For everyone who doesn't understand metatypes and our problem, please see:
>
> https://gist.github.com/Anton3/25a66751812f14f76cacc5e382339522
>
> Read it from beginning to ending and ask if you don't understand something!
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
swift-evolution at swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160722/d6acc54d/attachment.html>