<html><head><style>
body {
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
padding:1em;
margin:auto;
background:#fefefe;
}
h1, h2, h3, h4, h5, h6 {
font-weight: bold;
}
h1 {
color: #000000;
font-size: 28pt;
}
h2 {
border-bottom: 1px solid #CCCCCC;
color: #000000;
font-size: 24px;
}
h3 {
font-size: 18px;
}
h4 {
font-size: 16px;
}
h5 {
font-size: 14px;
}
h6 {
color: #777777;
background-color: inherit;
font-size: 14px;
}
hr {
height: 0.2em;
border: 0;
color: #CCCCCC;
background-color: #CCCCCC;
display: inherit;
}
p, blockquote, ul, ol, dl, li, table, pre {
margin: 15px 0;
}
a, a:visited {
color: #4183C4;
background-color: inherit;
text-decoration: none;
}
#message {
border-radius: 6px;
border: 1px solid #ccc;
display:block;
width:100%;
height:60px;
margin:6px 0px;
}
button, #ws {
font-size: 12 pt;
padding: 4px 6px;
border-radius: 5px;
border: 1px solid #bbb;
background-color: #eee;
}
code, pre, #ws, #message {
font-family: Monaco;
font-size: 10pt;
border-radius: 3px;
background-color: #F8F8F8;
color: inherit;
}
code {
border: 1px solid #EAEAEA;
margin: 0 2px;
padding: 0 5px;
}
pre {
border: 1px solid #CCCCCC;
overflow: auto;
padding: 4px 8px;
}
pre > code {
border: 0;
margin: 0;
padding: 0;
}
#ws { background-color: #f8f8f8; }
.bloop_markdown table {
border-collapse: collapse;
font-family: Helvetica, arial, freesans, clean, sans-serif;
color: rgb(51, 51, 51);
font-size: 15px; line-height: 25px;
padding: 0; }
.bloop_markdown table tr {
border-top: 1px solid #cccccc;
background-color: white;
margin: 0;
padding: 0; }
.bloop_markdown table tr:nth-child(2n) {
background-color: #f8f8f8; }
.bloop_markdown table tr th {
font-weight: bold;
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr td {
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr th :first-child, table tr td :first-child {
margin-top: 0; }
.bloop_markdown table tr th :last-child, table tr td :last-child {
margin-bottom: 0; }
.bloop_markdown blockquote{
border-left: 4px solid #dddddd;
padding: 0 15px;
color: #777777; }
blockquote > :first-child {
margin-top: 0; }
blockquote > :last-child {
margin-bottom: 0; }
code, pre, #ws, #message {
word-break: normal;
word-wrap: normal;
}
hr {
display: inherit;
}
.bloop_markdown :first-child {
-webkit-margin-before: 0;
}
code, pre, #ws, #message {
font-family: Menlo, Consolas, Liberation Mono, Courier, monospace;
}
.send { color:#77bb77; }
.server { color:#7799bb; }
.error { color:#AA0000; }</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="bloop_markdown"><p>Updated with changes written by Anton: <a href="https://github.com/DevAndArtist/swift-evolution/blob/rename_t_dot_type/proposals/0126-rename-t-dot-type.md">https://github.com/DevAndArtist/swift-evolution/blob/rename_t_dot_type/proposals/0126-rename-t-dot-type.md</a></p>
<hr>
<h2 id="introduction">Introduction</h2>
<p>This proposal renames <code>T.Type</code> to <code>Metatype<T></code>, renames <code>type(of:)</code> to <code>metatype(of:)</code> and removes <code>P.Protocol</code> metatypes.</p>
<p>Swift-evolution threads: </p>
<ul>
<li><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/025115.html">[Revision] [Pitch] Rename <code>T.Type</code></a></li>
<li><a href="">[Review] SE–0126: Refactor Metatypes, repurpose T[dot]self and Mirror</a></li>
<li><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160718/024772.html">[Proposal] Refactor Metatypes, repurpose T[dot]self and Mirror</a></li>
<li><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160704/023818.html">[Discussion] Seal <code>T.Type</code> into <code>Type<T></code></a></li>
</ul>
<h2 id="motivation">Motivation</h2>
<p></p><details><summary>Explanation of metatypes</summary><p></p>
<p>For every type <code>T</code> in Swift, there is an associated metatype <code>T.Type</code>.</p>
<h3 id="basics:functionspecialization">Basics: function specialization</h3>
<p>Let’s try to write a generic function like <code>staticSizeof</code>. We will only consider its declaration; implementation is trivial and unimportant here.</p>
<p>Out first try would be:</p>
<pre><code class="swift">func staticSizeof<T>() -> Int
staticSizeof<Float>() // error :(
</code></pre>
<p>Unfortunately, it’s an error. We can’t explicitly specialize generic functions in Swift. Second try: we pass a parameter to our function and get generic type parameter from it:</p>
<pre><code class="swift">func staticSizeof<T>(_: T) -> Int
staticSizeof(1) //=> should be 8
</code></pre>
<p>But what if our type <code>T</code> was a bit more complex and hard to obtain? For example, think of <code>struct Properties</code> that loads a file on initialization:</p>
<pre><code class="swift">let complexValue = Properties("the_file.txt") // we have to load a file
staticSizeof(complexValue) // just to specialize a function
</code></pre>
<p>Isn’t that weird? But we can work around that limitation by passing instance of a dummy generic type:</p>
<pre><code class="swift">struct Dummy<T> { }
func staticSizeof<T>(_: Dummy<T>) -> Int
staticSizeof(Dummy<Properties>())
</code></pre>
<p>This is the main detail to understand: we <strong>can</strong> explicitly specialize generic types, and we <strong>can</strong> infer generic type parameter of function from generic type parameter of passed instance. Now, surprise! We’ve already got <code>Dummy<T></code> in the language: it’s called <code>T.Type</code> and created using <code>T.self</code>:</p>
<pre><code class="swift">func staticSizeof<T>(_: T.Type) -> Int
staticSizeof(Float.self)
</code></pre>
<p>But there’s a lot more to <code>T.Type</code>. Sit tight.</p>
<h3 id="subtyping">Subtyping</h3>
<p>Internally, <code>T.Type</code> stores identifier of a type. Specifically, <code>T.Type</code> can refer to any <strong>subtype</strong> of <code>T</code>. With enough luck, we can also cast instances of metatypes to other metatypes. For example, <code>Int : CustomStringConvertible</code>, so we can do this:</p>
<pre><code class="swift">let subtype = Int.self
metaInt //=> Int
let supertype = subtype as CustomStringConvertible.Type
supertype //=> Int
</code></pre>
<p>Here, <code>supertype : CustomStringConvertible.Type</code> can refer to <code>Int</code>, to <code>String</code> or to any other <code>T : CustomStringConvertible</code>.
We can also use <code>as?</code>, <code>as!</code> and <code>is</code> to check subtyping relationships. We’ll only show examples with <code>is</code>:</p>
<pre><code class="swift">Int.self is CustomStringConvertible.Type //=> true
</code></pre>
<pre><code class="swift">protocol Base { }
protocol Derived: Base { }
Derived.self is Base.Type //=> true
</code></pre>
<pre><code class="swift">protocol Base { }
struct Derived: Base { }
let someBase = Derived.self as Base.Type
// ...
someBase is Derived.Type //=> true
</code></pre>
<p>A common practise is to store metatypes <code>as Any.Type</code>. When needed, we can check all required conformances.</p>
<h3 id="dynamicdispatchofstaticmethods">Dynamic dispatch of static methods</h3>
<p>If we have an instance of <code>T.Type</code>, we can call static methods of <code>T</code> on it:</p>
<pre><code class="swift">struct MyStruct {
static func staticMethod() -> String { return "Hello metatypes!" }
}
let meta = MyStruct.self
meta.staticMethod() //=> Hello metatypes!
</code></pre>
<p>What is especially useful, if our <code>T.self</code> actually stores some <code>U : T</code>, then static method of <code>U</code> will be called:</p>
<pre><code class="swift">protocol HasStatic { static func staticMethod() -> String }
struct A: HasStatic { static func staticMethod() -> String { return "A" } }
struct B: HasStatic { static func staticMethod() -> String { return "B" } }
var meta: HasStatic.Type
meta = A.self
meta.staticMethod() //=> A
meta = B.self
meta.staticMethod() //=> B
</code></pre>
<p>Summing that up, metatypes have far deeper semantics than a tool for specialization of generic functions. They combine dynamic information about a type with static information “contained type is a subtype of <em>this</em>”. They can also dynamically dispatch static methods the same way as normal methods are dynamically dispatched.
</p></details><p></p>
<h3 id="currentbehaviorof.protocol">Current behavior of <code>.Protocol</code></h3>
<p>For protocols <code>P</code>, besides normal <code>P.Type</code>, there is also a “restricting metatype” <code>P.Protocol</code> that is the same as <code>P.Type</code>, except that it can only reflect <code>P</code> itself and not any of its subtypes:</p>
<pre><code class="swift">Int.self is CustomStringConvertible.Type //=> true
Int.self is CustomStringConvertible.Protocol //=> false
</code></pre>
<p>Even without <code>P.Protocol</code>, we can test for equality:</p>
<pre><code class="swift">Int.self is CustomStringConvertible.Type //=> true
Int.self == CustomStringConvertible.self //=> false
</code></pre>
<p>For protocols <code>P</code>, <code>P.self</code> returns a <code>P.Protocol</code>, not <code>P.Type</code>:</p>
<pre><code class="swift">let metatype = CustomStringConvertible.self
print(type(of: metatype)) //=> CustomStringConvertible.Protocol
</code></pre>
<p>In practise, the existence of <code>P.Protocol</code> creates problems. If <code>T</code> is a generic parameter, then <code>T.Type</code> turns into <code>P.Protocol</code> if a protocol <code>P</code> is passed:</p>
<pre><code class="swift">func printMetatype<T>(_ meta: T.Type) {
print(dynamicType(meta))
let copy = T.self
print(dynamicType(copy))
}
printMetatype(CustomStringConvertible.self) //=> CustomStringConvertible.Protocol x2
</code></pre>
<p>Lets review the following situation:</p>
<pre><code class="swift">func isIntSubtype<T>(of: T.Type) -> Bool {
return Int.self is T.Type
}
isIntSubtype(of: CustomStringConvertible.self) //=> false
</code></pre>
<p>Now we understand that because <code>T</code> is a protocol <code>P</code>, <code>T.Type</code> turns into a <code>P.Protocol</code>, and we get the confusing behaviour.</p>
<p>Summing up issues with <code>P.Protocol</code>, it does not bring any additional functionality (we can test <code>.Type</code>s for <code>is</code> and for <code>==</code>),
but tends to appear unexpectedly and break subtyping with metatypes.</p>
<h3 id="evenmoreissueswith.protocol">Even more issues with <code>.Protocol</code></h3>
<blockquote>
<p>[1] When <code>T</code> is a protocol <code>P</code>, <code>T.Type</code> is the metatype of the protocol type itself, <code>P.Protocol</code>. <code>Int.self</code> is not <code>P.self</code>.</p>
<p>[2] There isn’t a way to generically expression <code>P.Type</code> <strong>yet</strong>.</p>
<p>[3] The syntax would have to be changed in the compiler to get something that behaves like <code>.Type</code> today.</p>
<p>Written by Joe Groff: <a href="https://twitter.com/jckarter/status/754420461404958721">[1]</a> <a href="https://twitter.com/jckarter/status/754420624261472256">[2]</a> <a href="https://twitter.com/jckarter/status/754425573762478080">[3]</a></p>
</blockquote>
<p>There is a workaround for <code>isIntSubtype</code> example above. If we pass a <code>P.Type.Type</code>, then it turns into <code>P.Type.Protocol</code>, but it is still represented with <code>.Type</code> in generic contexts. If we manage to drop outer <code>.Type</code>, then we get <code>P.Type</code>:</p>
<pre><code class="swift">func isIntSubtype<T>(of _: T.Type) -> Bool {
return Int.self is T // not T.Type here anymore
}
isIntSubtype(of: CustomStringConvertible.Type.self) //=> true
</code></pre>
<p>In this call, <code>T = CustomStringConvertible.Type</code>. We can extend this issue and find the second problem by checking against the metatype of <code>Any</code>:</p>
<pre><code class="swift">func isIntSubtype<T>(of _: T.Type) -> Bool {
return Int.self is T
}
isIntSubtype(of: Any.Type.self) //=> true
isIntSubtype(of: Any.self) //=> true
</code></pre>
<p>When using <code>Any</code>, the compiler does not require <code>.Type</code> and returns <code>true</code> for both variations.</p>
<p>The third issue shows itself when we try to check protocol relationship with another protocol. Currently, there is no way (that we know of) to solve this problem:</p>
<pre><code class="swift">protocol Parent {}
protocol Child : Parent {}
func isChildSubtype<T>(of _: T.Type) -> Bool {
return Child.self is T
}
isChildSubtype(of: Parent.Type.self) //=> false
</code></pre>
<p>We also believe that this issue is the reason why the current global functions <code>sizeof</code>, <code>strideof</code> and <code>alignof</code> make use of generic <code><T>(_: T.Type)</code> declaration notation instead of <code>(_: Any.Type)</code>.</p>
<h3 id="magicalmembers">Magical members</h3>
<p>There were the following “magical” members of all types/instances:</p>
<ul>
<li><code>.dynamicType</code>, which was replaced with <code>type(of:)</code> function by SE–0096.</li>
<li><code>.Type</code> and <code>.Protocol</code>, which we propose to remove, see below.</li>
<li><code>.Self</code>, which acts like an <code>associatedtype</code>.</li>
<li><code>.self</code>, which will be reviewed in a separate proposal.</li>
</ul>
<p>The tendency is to remove “magical” members: with this proposal there will only be <code>.Self</code> (does not count) and <code>.self</code>.</p>
<p>Also, <code>.Type</code> notation works like a generic type, and giving it generic syntax seems to be a good idea (unification).</p>
<h2 id="proposedsolution">Proposed solution</h2>
<ul>
<li>Remove <code>P.Protocol</code> type without a replacement. <code>P.self</code> will never return a <code>P.Protocol</code>.</li>
<li>Rename <code>T.Type</code> to <code>Metatype<T></code>.</li>
<li>Rename <code>type(of:)</code> function from SE–0096 to <code>metatype(of:)</code>.</li>
</ul>
<h2 id="impactonexistingcode">Impact on existing code</h2>
<p>This is a source-breaking change that can be automated by a migrator. All occurrences of <code>T.Type</code> and <code>T.Protocol</code> will be changed to <code>Metatype<T></code>. All usages of <code>type(of:)</code> will be changed to <code>metatype(of:)</code></p>
<h2 id="alternativesconsidered">Alternatives considered</h2>
<ul>
<li>Rename <code>T.self</code> to <code>T.metatype</code>. However, this can be proposed separately.</li>
<li>Use <code>Type<T></code> instead of <code>Metatype<T></code>. However, <code>Metatype</code> is more precise here.</li>
</ul>
<p></p></div><div class="bloop_original_html"><style>body{font-family:Helvetica,Arial;font-size:13px}</style><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div> <br> <div id="bloop_sign_1469279877722086912" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div></div><div class="bloop_markdown"><p></p></div></body></html>