<div dir="ltr">Sorry, my question at least has nothing to do with bikeshedding. I'm confused about why the proposal feels it's necessary to have both Type and Subtype. I don't understand Brent's two reasons and was hoping for some elaboration. I'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"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></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<T></code> or other suggested names looked like <code>ExactType<T></code>, <code>StaticType<T></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<T></code> with <code>T.self</code> or shadow a concrete type behind <code>Subtype<U></code> with <code>subtype(of:)</code> function.</p>
<p>To be precise the correct names should be:</p>
<ul>
<li><code>Metatype<T></code> for the concrete type (#1).</li>
<li><code>ExistentialMetatype<T></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<T></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 //=> true `P.Type` is the existential type here
anyMetatype is A.Type //=> true
let aMetatype = anyMetatype as! A.Type // Okay
// today `type(of:)` does the same trick
// After this proposal:
// subtype<T>(of instance: T) -> Subtype<T>
// The function will extract `Type<A>` for `any` but shadow it behind `Subtype<Any>`
let anyMetatype: `Subtype<Any>` = subtype(of: any)
// The correct relationship look like this:
// Subtype<P> : Subtype<Any>
// Subtype<A> : Subtype<P>
// Type<A> : Subtype<A>
anyMetatype is Subtype<P> //=> true
anyMetatype is Subtype<A> //=> true
anyMetatype is Type<A> //=> true
anyMetatype is Type<P> //=> false
anyMetatype is Type<Any> //=> false
let aMetatype_1 = anyMetatype as! Subtype<A> // Okay
let aMetatype_2 = anyMetatype as! Type<A> // 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<T></code> where in reality it’s a concrete metatype <code>Type<U></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:"helvetica neue",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<T> and SubTypeOf<T> 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>