<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPad</div><div><br>On Jun 2, 2016, at 4:47 PM, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><div style="white-space:pre-wrap">Isn't this the same argument for .dynamicType over type(of:) though?<br><br>Given that that debate has been settled in favor of the latter, I think the question today is how best to come up with a consistent scheme.<br><br>Earlier in this conversation, it was pointed out (by Matt, I think?) that one key advantage of type(of:) is that it takes on a syntax that is actually possible to write in Swift, since one cannot extend Any.<br></div></div></blockquote><div><br></div><div>Yep, IMO we should stick with the strategy that if something *looks* like a user-definable construct it should be possible to at least write the declaration even if it wouldn't be possible to implement. &nbsp;That rules out static or instance properties or methods that apply to all types.</div><br><blockquote type="cite"><div><div style="white-space:pre-wrap"><br>If we take this principle to its logical conclusion, properties (of a type or instance) which apply to Any should be global functions.<br></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 2, 2016 at 16:26 Russ Bishop &lt;<a href="mailto:xenadu@gmail.com">xenadu@gmail.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Jun 2, 2016, at 2:05 PM, Xiaodi Wu &lt;<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>&gt; wrote:</div><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><br><div><br></div><div>In the earlier conversation, it was pointed out (by Dave A., I think?) that examples such as Array.size show how this solution can get confusing. And even though there aren't fixed-length arrays in Swift, those may come one day, making the syntax even more confusing.</div></div></div></div></div></blockquote></div><br><div><br></div></div><div style="word-wrap:break-word"><div>Array.count is a function taking an instance; I’m not sure I agree it would be terribly confusing… then again I run in Xcode with the quick help pane open so I see the doc comments for every type, property, and function as I move around the code. It’s quite handy :)</div><div><br></div><div>I could see including memory in the name (or something similar) if we want to be extra clear about it.</div><div><br></div><div>&nbsp; &nbsp; Int.memorySize</div><div>&nbsp; &nbsp; Int.memoryAlignment</div><div><br></div><div><br></div><div>Ultimately the type’s size in memory <i>is a property of the type</i> so it seems clear that is where it belongs (being careful not to steal too much of the namespace of course).</div></div><div style="word-wrap:break-word"><div><br></div><div><br></div><div>Russ</div></div></blockquote></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></body></html>