<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Jun 2, 2016, at 2:05 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 2, 2016 at 3:46 PM, John McCall via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><span class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 2, 2016, at 1:43 PM, Russ Bishop <<a href="mailto:xenadu@gmail.com" target="_blank" class="">xenadu@gmail.com</a>> wrote:</div><div class=""><div style="word-wrap:break-word" class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class="">I still think the value-based APIs are misleading and that it would be better to ask people to just use a type explicitly.</div><div class=""><br class=""></div><div class="">John.</div></div></div></blockquote></div><br class=""><div class=""><br class=""></div><div class="">I agree; in fact <i class="">why aren’t these properties on the type itself</i>? The type is what matters; why can’t the type just tell me it’s size? </div><div class="">Having free functions or magic operators seems to be another holdover from C. </div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""> Int.size</font></div><div class=""><font face="Monaco" class=""> Int.alignment</font></div><div class=""><font face="Monaco" class=""> Int.spacing</font></div><div class=""><font face="Monaco" class=""><br class=""></font></div><div class=""><font face="Monaco" class=""> let x: Any = 5</font></div><div class=""><font face="Monaco" class=""> type(of: x).size</font></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">The compiler should be able to statically know the first three values and inline them. The second is discovering the size dynamically.</div></div></div></blockquote><div class=""><br class=""></div></div></span>Two reasons. The first is that this is a user-extensible namespace via static members, so it's somewhat unfortunate to pollute it with names from the library. The second is that there's currently no language mechanism for adding a static member to every type, so this would have to be built-in. But I agree that in the abstract a static property would be preferable.</div></blockquote><div class=""><br class=""></div><div class="">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><br class=""></div><div>Yes, I think that it is clear that, even if we added a property on all types, it would not be acceptable to name that property something like "size"; it would have to be something longer like "storageSize".</div><div><br class=""></div><div>John.</div><br class=""></body></html>