<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I wouldn’t be surprised if there are less than a handful of people outside of the Swift team who understand what .Protocol means. </div><div class=""><br class=""></div><div class="">Most of us just want to create generic objects based on their conformance to an initialiser in a protocol:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">protocol Constructable {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>init()</div><div class="">}</div><div class=""><br class=""></div><div class="">func construct<C:Constructable>() -> C {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>return C() // ERROR</div><div class="">}</div></blockquote><div class=""><br class=""></div><div class="">Karl</div><br class=""><div><blockquote type="cite" class=""><div class="">On 22 Jul 2016, at 15:19, Anton Zhilin via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Interesting, it looks like only Joe Groff understands what .Protocol means and considers it important. And a couple others, maybe.<div class=""><br class=""></div><div class="">Copying my metatypes explanation link:</div><div class=""><div class="">For everyone who doesn't understand metatypes and our problem, please see</div><div class=""><a href="https://gist.github.com/Anton3/25a66751812f14f76cacc5e382339522" class="">https://gist.github.com/Anton3/25a66751812f14f76cacc5e382339522</a></div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">2016-07-22 16:07 GMT+03:00 Adrian Zubarev via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span>:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><p class="">Hello everyone,</p><p class="">recently I was pinged on twitter to a conversation between Jacob Bandes-Storch, Joe Groff and Slava Pestov.</p><p class="">Here is the conversation covering a few more facts about the mysterious <code class="">.Protocol</code>:</p>
<blockquote class=""><p class=""><strong class="">[Jacob Bandes-Storch]</strong> Was hoping to just define <code class="">type<T>(of x: T) -> T.Type</code> and move <code class="">impl</code> of <code class="">emitMetatypeOfValue()</code> there.</p><p class=""><strong class="">[Joe Groff]</strong> Yeah, that won’t do the right thing for existentials compared to <code class="">x.dynamicType</code>.</p><p class=""><strong class="">[Jacob Bandes-Storch]</strong> When you say “do the right thing” you mean the return type? Shouldn’t <code class="">type(of x: Proto) -> Proto.Type</code>?</p><p class=""><strong class="">[Slava Pestov]</strong> Right, but if <code class="">T := P</code>, then <code class="">T.Type</code> is <code class="">P.Protocol</code>, not <code class="">P.Type</code></p><p class=""><strong class="">[Jacob Bandes-Storch]</strong> Mind bending… Suppose <code class="">T : P</code>, <code class="">x : P = T()</code>, then <code class="">type(of: x)</code> returns <code class="">T</code>, and <code class="">T: P.Type</code>. What am I missing?</p><p class=""><strong class="">[Joe Groff]</strong> <code class="">P.Type</code> is really <code class="">Any<P.Type></code>, and <code class="">P.Protocol</code> is really <code class="">(Any<P>).Type</code>. If <code class="">T == Any<P></code>, <code class="">T.Type == latter</code></p><p class=""><strong class="">[Joe Groff]</strong> <code class="">dynamicType</code> is different for existentials: open existential, take opened metatype, erase to <code class="">e.metatype</code></p><p class=""><strong class="">[Jacob Bandes-Storch]</strong> Now I’m confused by current behavior: <a href="https://gist.github.com/jtbandes/7624fef93eb23010c032b2d1fd3674be#file-dynamictype-swift-L12" target="_blank" class="">GIST</a> … isn’t dynamicType’s job to return <code class="">T.self</code>?</p><p class=""><strong class="">[Joe Groff]</strong> invokes `foo() on the opened type, then re-closes an existential around the result if Self is involved</p><p class=""><strong class="">[Jacob Bandes-Storch]</strong> But this does what I’d expect: <a href="https://gist.github.com/jtbandes/7624fef93eb23010c032b2d1fd3674be#file-dynamictype-swift-L23" target="_blank" class="">GIST</a></p><p class=""><strong class="">[Joe Groff]</strong> Right, member lookup also implicitly opens an existential.</p><p class=""><strong class="">[Jacob Bandes-Storch]</strong> Point being that there’s no way to do this for generic params?</p><p class=""><strong class="">[Joe Groff]</strong> Not in argument position. Only ‘self’ gets this magic behavior.</p><p class=""><strong class="">[Jacob Bandes-Storch]</strong> Is that a bug or feature? Seems to me dynamicType should always be able to get the actual runtime type.</p><p class=""><strong class="">[Joe Groff]</strong> Consider this situation:</p>
<pre class=""><code class="">func foo<T>(x:T) -> (T.Type, T.Type) {
return (T.self, x.dynamicType)
}
</code></pre><p class=""><strong class="">[Jacob Bandes-Storch]</strong> Still struggling to see what’s wrong with returning “real” type. What can be subst. for `T that breaks it?</p><p class=""><strong class="">[Joe Groff]</strong> Consider <code class="">T == P</code> with <code class="">x.dynamicType</code> trying to produce the existential dynamic type.</p><p class=""><strong class="">[Jacob Bandes-Storch]</strong> I think I’m mostly confused because <code class="">P.Type</code> vs. <code class="">P.Protocol</code> is really non-obvious. Has renaming been discussed?</p><p class=""><strong class="">[Joe Groff]</strong> The gotcha mainly comes up if you try to replicate the builtin behavior. Most people don’t try to do that.</p><p class=""><strong class="">[Jacob Bandes-Storch]</strong> Would it make sense to disallow <code class="">x.dynamicType</code> in such cases? Gotcha would be less confusing if forced to say `T.self.</p>
</blockquote><div class=""><br class="webkit-block-placeholder"></div></div><div class=""><span class=""><div style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><br class=""></div> <br class=""> <div class=""><div style="font-family:helvetica,arial;font-size:13px" class="">-- <br class="">Adrian Zubarev<br class="">Sent with Airmail</div></div> <br class=""></span><div class=""><div class="h5"><p class="">Am 22. Juli 2016 um 14:47:08, Vladimir.S via swift-evolution (<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>) schrieb:</p> <blockquote type="cite" class=""><span class=""><div class=""><div class=""></div><div class="">Thank you for the article. Very informative.<br class=""><br class="">So, I believe core team can answer the question : "..why P.Protocol is <br class="">needed" and if we can remove it without problems.<br class=""><br class=""><br class="">Small fix - A&B should have ': HasStatic' and closing bracket here:<br class=""><br class="">protocol HasStatic { static func staticMethod() }<br class="">struct A { static func staticMethod() -> String { return "A" }<br class="">struct B { static func staticMethod() -> String { return "B" }<br class=""><br class=""><br class="">On 22.07.2016 14:40, Anton Zhilin via swift-evolution wrote:<br class="">> For everyone who doesn't understand metatypes and our problem, please see:<br class="">><br class="">> <a href="https://gist.github.com/Anton3/25a66751812f14f76cacc5e382339522" target="_blank" class="">https://gist.github.com/Anton3/25a66751812f14f76cacc5e382339522</a><br class="">><br class="">> Read it from beginning to ending and ask if you don't understand something!<br class="">><br class="">><br class="">> _______________________________________________<br class="">> swift-evolution mailing list<br class="">> <a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></span></blockquote></div></div></div><div class=""><div class=""><br class="webkit-block-placeholder"></div></div></div><br class="">_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>