<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 <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> 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. 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 <<a href="mailto:xenadu@gmail.com">xenadu@gmail.com</a>> 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 <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> 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> Int.memorySize</div><div> 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>