<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br>Regards<div>LM</div><div>(From mobile)</div></div><div><br>On Jul 13, 2016, at 2:02 PM, Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><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><div class="bloop_markdown"><p>This isn’t a full proposal (yet). We still can change things. I didn’t consider everything and can’t to that on my own. Feedback is welcome.</p>
<p>To answer your question, we still need the metatype to access initializer and static member of that type. If we’d drop T.Type completely, we’d lose functionality to do so.</p>
<pre><code class="swift">protocol A {
init()
}
func foo<T : A>(metatype: T.Type) -> T {
return metatype.init()
}
</code></pre>
<p>The downside of this proposal is the bottleneck property to access that functionality, otherwise adding <code>Hashable</code> or other things like <code>size</code> (MemoryLayout) won’t be possible without serious compiler magic. So do I believe.</p>
<pre><code class="swift">func foo<T : A>(type: Type<T>) -> T {
return type.metatype.init()
}
</code></pre>
<p>This is huge tradeoff, but it’s worth considering if the community can life with that.</p>
<p>Furthermore as already been mentioned in this thread, we might consider to extend <code>Type<T></code> to add reflection functionality to it. (If we’d decide to go in that direction.)</p></div></div></blockquote><div>IMHO it is not just a matter of 'adding reflection'.. this IS a subset of reflection. The key is to design it question exhaustively enough to leave clean holes for the rest being only additive. Otherwise this will lead the way to more 'oops we have to change the proposal so that what we loose now can be put back additively later' (reference to the recent dance around the labels in sigs proposal that had to be patched post-acceptance)</div><div><div><br></div><div><br></div><br><blockquote type="cite"><div><div class="bloop_original_html"> <br> <div id="bloop_sign_1468409643858804992" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div> <br><p class="airmail_on">Am 13. Juli 2016 um 13:15:02, Anton Zhilin (<a href="mailto:antonyzhilin@gmail.com">antonyzhilin@gmail.com</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>
<title></title>
<div dir="ltr">Why can't we drop metatypes T.Type with your
proposal? Do they bring some extra capabilities over Type<T>
struct? </div>
</div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote><style>body{font-family:Helvetica,Arial;font-size:13px}</style></div></body></html>