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

[Karl]

I wouldn’t be surprised if there are less than a handful of people outside of the Swift team who understand what .Protocol means. 

Most of us just want to create generic objects based on their conformance to an initialiser in a protocol:

protocol Constructable {
	init()
}

func construct<C:Constructable>() -> C {
	return C()                                               // ERROR
}

Karl

> On 22 Jul 2016, at 15:19, Anton Zhilin via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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 <https://gist.github.com/Anton3/25a66751812f14f76cacc5e382339522>
> 
> 2016-07-22 16:07 GMT+03:00 Adrian Zubarev via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto: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 <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 <mailto:swift-evolution at swift.org>
>> > https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> >
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/cfaadea5/attachment.html>