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

[Anton Zhilin]

Interesting, it looks like only Joe Groff understands what .Protocol means
and considers it important. And a couple others, maybe.

Copying my metatypes explanation link:
For everyone who doesn't understand metatypes and our problem, please see
https://gist.github.com/Anton3/25a66751812f14f76cacc5e382339522

2016-07-22 16:07 GMT+03:00 Adrian Zubarev via swift-evolution <
swift-evolution at swift.org>:

> 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
> <https://gist.github.com/jtbandes/7624fef93eb23010c032b2d1fd3674be#file-dynamictype-swift-L12>
> … 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
> <https://gist.github.com/jtbandes/7624fef93eb23010c032b2d1fd3674be#file-dynamictype-swift-L23>
>
> *[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
>
>
> _______________________________________________
> 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/a71d7ae1/attachment.html>