As I said above, I disagree. Unsafe things should have names that call attention to themselves. Safe things should not, *especially* if they&#39;re unsafe-adjacent. It&#39;s not useful in a line of code to have every part of it competing for your attention merely because they&#39;re typically used in conjunction with an unsafe operation. It&#39;s essential that the unsafe operation itself stand out.<br><br>Ever see a doctor clicking their mouse faster than a video gamer to dismiss 20 warnings in a row on a computer screen? That&#39;s what happens when everything unsafe-adjacent calls attention to itself.<br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 2, 2016 at 19:53 Matthew Johnson &lt;<a href="mailto:matthew@anandabits.com">matthew@anandabits.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 dir="auto"><div><br><br>Sent from my iPad</div></div><div dir="auto"><div><br>On Jun 2, 2016, at 4:25 PM, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; 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&#39;t quite apt.<br></div></blockquote><div><br></div></div><div dir="auto">These operations aren&#39;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><div dir="auto"><div><br><blockquote type="cite"><div><br>And I&#39;m not sure we really want to encourage anyone else to be defining a global function named size(of:) anyway, so I wouldn&#39;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 &lt;<a href="mailto:allevato@google.com" target="_blank">allevato@google.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 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&#39;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&#39;d like. I&#39;d like to see the word &quot;memory&quot; as part of the name somehow, whether it&#39;s a wrapping type or a function prefix of some sort. These values are specialized; we don&#39;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 &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; 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">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</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 &lt;<a href="mailto:xenadu@gmail.com" target="_blank">xenadu@gmail.com</a>&gt; 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 &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; 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&#39;s somewhat unfortunate to pollute it with names from the library.  The second is that there&#39;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&#39;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" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></div></blockquote></div>