<div dir="ltr">Sorry, my question at least has nothing to do with bikeshedding. I&#39;m confused about why the proposal feels it&#39;s necessary to have both Type and Subtype. I don&#39;t understand Brent&#39;s two reasons and was hoping for some elaboration. I&#39;ve tried to clarify my question in a gist:<div><br></div><div><a href="https://gist.github.com/xwu/0cc2c8d358f1fdf066ba739bcd151167">https://gist.github.com/xwu/0cc2c8d358f1fdf066ba739bcd151167</a></div><div><br><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 30, 2016 at 2:09 PM, Adrian Zubarev via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div class="gmail-m_6144360559732206633bloop_markdown"><p>About the proposed names:</p>

<p>To be crystal clear we could use more descriptive names for our two types. Today <code>T.Type</code> is referred as *metatype* and serving two different purposes at once.</p>

<ol>
<li><p>It’s a concrete type; we call it <code>Type&lt;T&gt;</code> or other suggested names looked like <code>ExactType&lt;T&gt;</code>, <code>StaticType&lt;T&gt;</code> etc.</p></li>
<li><p><code>T.Type</code> is also the <em>base type</em> for all subtypes of <code>T</code>.</p></li>
</ol>

<p>Protocols has one exception here.</p>

<p>1.1. The concrete type for protocols is not <code>T.Type</code> but <code>T.Protocol</code>.</p>

<p>2.1. <code>T.Protocol</code> has only one supertype, which is the existential (#2) <code>Any.Type</code> type.</p>

<p>Our proposal slices this behaviour into two different types, where you only can create a *concrete type* <code>Type&lt;T&gt;</code> with <code>T.self</code> or shadow a concrete type behind <code>Subtype&lt;U&gt;</code> with <code>subtype(of:)</code> function.</p>

<p>To be precise the correct names should be:</p>

<ul>
<li><code>Metatype&lt;T&gt;</code> for the concrete type (#1).</li>
<li><code>ExistentialMetatype&lt;T&gt;</code> for the existential type (#2).</li>
</ul>

<p>But we felt that we should adopt the existing name from <code>T.Type</code> and use the short form for the *concrete type* <code>Type&lt;T&gt;</code>.</p>

<hr>

<p>Brent already showed in multiple examples but the question seems to come up over and over about the correct name of the current <code>type(of:)</code> function.</p>

<p>Imagine this scenario:</p>

<pre><code class="gmail-m_6144360559732206633swift">protocol P {}
struct A : P {}

let proto: P = A()
let any: Any = proto

// the old behaviour looked like this

// *concrete* `A.Type` is hidden behind the existential `Any.Type`
let anyMetatype: Any.Type = any.dynamicType  

anyMetatype is P.Type //=&gt; true `P.Type` is the existential type here
anyMetatype is A.Type //=&gt; true
let aMetatype = anyMetatype as! A.Type // Okay

// today `type(of:)` does the same trick

// After this proposal:
// subtype&lt;T&gt;(of instance: T) -&gt; Subtype&lt;T&gt;

// The function will extract `Type&lt;A&gt;` for `any` but shadow it behind `Subtype&lt;Any&gt;`
let anyMetatype: `Subtype&lt;Any&gt;` = subtype(of: any)

// The correct relationship look like this:
// Subtype&lt;P&gt; : Subtype&lt;Any&gt;
// Subtype&lt;A&gt; : Subtype&lt;P&gt;
// Type&lt;A&gt; : Subtype&lt;A&gt;

anyMetatype is Subtype&lt;P&gt; //=&gt; true
anyMetatype is Subtype&lt;A&gt; //=&gt; true
anyMetatype is Type&lt;A&gt;    //=&gt; true
anyMetatype is Type&lt;P&gt;    //=&gt; false
anyMetatype is Type&lt;Any&gt;  //=&gt; false
let aMetatype_1 = anyMetatype as! Subtype&lt;A&gt; // Okay
let aMetatype_2 = anyMetatype as! Type&lt;A&gt;    // Okay
</code></pre>

<p><code>subtype(of:)</code> function extracts the *concrete type* from the given instance but shadows it behind the *existential type* equal to the type of the given instance.</p>

<p><code>subtype(of: T)</code> returns a existential metatype instance <code>Subtype&lt;T&gt;</code> where in reality it’s a concrete metatype <code>Type&lt;U&gt;</code> with the relationship like <code>U : T</code>.</p>

<p>This is exact the same behaviour as the old <code>.dynamicType</code> had.</p>

<p>I hope that cleared some raising questions. </p>

<p></p></div><div class="gmail-m_6144360559732206633bloop_original_html"><span class="gmail-"><div id="gmail-m_6144360559732206633bloop_customfont" style="font-family:helvetica,arial;font-size:13px;color:rgb(0,0,0);margin:0px"><br></div> <br> <div id="gmail-m_6144360559732206633bloop_sign_1475260675378149888" class="gmail-m_6144360559732206633bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div> <br></span><span class="gmail-"><p class="gmail-m_6144360559732206633airmail_on">Am 30. September 2016 um 09:00:53, Goffredo Marocchi via swift-evolution (<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>) schrieb:</p> <blockquote type="cite" class="gmail-m_6144360559732206633clean_bq"><span><div><span style="color:rgb(0,0,0);font-family:&quot;helvetica neue&quot;,helvetica;font-size:14px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);float:none;display:inline">Calling it SuperTypeOf&lt;T&gt; and SubTypeOf&lt;T&gt; would make it less confusing as that is how I read it in my mind in your last example.</span></div></span></blockquote></span></div><div class="gmail-m_6144360559732206633bloop_markdown"><p></p></div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div></div></div>