<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:25 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>On the other hand, on its own sizeof() is not unsafe, and so the argument that it should be longer to call attention to itself (by analogy with UnsafePointer) isn't quite apt.<br></div></blockquote><div><br></div>These operations aren't themselves unsafe. But they are low level details that are not useful unless you are doing something that requires special care. A name that stands out more calls attention to the surrounding code. That is a good thing IMO.<div><br><blockquote type="cite"><div><br>And I'm not sure we really want to encourage anyone else to be defining a global function named size(of:) anyway, so I wouldn't consider vacating that name for end-user purposes to be a meaningful positive.<br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 2, 2016 at 16:15 Tony Allevato <<a href="mailto:allevato@google.com">allevato@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Given that these are fairly low-level values with very specialized uses, I definitely agree that they should be somehow namespaced in a way that doesn't cause us to make very common words unusable for our users.<div><br></div><div>Even size(of:) seems more general to me than I'd like. I'd like to see the word "memory" as part of the name somehow, whether it's a wrapping type or a function prefix of some sort. These values are specialized; we don't need to optimize typing them, IMO.</div></div><br><div class="gmail_quote"></div><div class="gmail_quote"><div dir="ltr">On Thu, Jun 2, 2016 at 2:06 PM Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><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"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span><div><blockquote type="cite"><div>On Jun 2, 2016, at 1:43 PM, Russ Bishop <<a href="mailto:xenadu@gmail.com" target="_blank">xenadu@gmail.com</a>> wrote:</div><div><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><div><div style="word-wrap:break-word"><div><br></div><div>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><br></div><div>John.</div></div></div></blockquote></div><br><div><br></div><div>I agree; in fact <i>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>Having free functions or magic operators seems to be another holdover from C. </div><div><br></div><div><br></div><div><font face="Monaco"> Int.size</font></div><div><font face="Monaco"> Int.alignment</font></div><div><font face="Monaco"> Int.spacing</font></div><div><font face="Monaco"><br></font></div><div><font face="Monaco"> let x: Any = 5</font></div><div><font face="Monaco"> type(of: x).size</font></div><div><br></div><div><br></div><div>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><br></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><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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><br></div></div></div></div></blockquote></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></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></div></body></html>