<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="">+1 on #3<div class="">3. MemoryLayout<Int>.size</div><div class=""><br class=""></div><div class=""><a href="http://i.gifntext.com/29412-number-3-my-lord.gif" class="">http://i.gifntext.com/29412-number-3-my-lord.gif</a></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 6, 2016, at 3:37 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class="">on Mon Jun 06 2016, Nate Cook <<a href="http://natecook-at-gmail.com" class="">natecook-AT-gmail.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">I'd like to cast another vote in favor of something like the<br class="">MemoryLayout struct. In general, people aren't always making the right<br class="">choice about which of these values to use. Combining them into one<br class="">data type would mean they see that there are three related values and<br class="">can find out when to use which easily.<br class=""><br class="">Would MemoryLayout need to be generic? Accessing a static property on<br class="">a generic type doesn't seem as straightforward as a function call or<br class="">the properties of a struct. I think I'd prefer something closer to the<br class="">way Mirror works, but really, I defer to those with stronger<br class="">convictions / actual reasons:<br class=""><br class="">func type<T>(of value: T) -> T.Type {<br class=""> return T.self<br class="">}<br class=""><br class="">struct MemoryLayout {<br class=""> let size: Int<br class=""> let stride: Int<br class=""> let alignment: Int<br class=""><br class=""> init<T>(of type: T.Type) {<br class=""></blockquote><br class="">I see no need for an argument label here.<br class=""><br class=""><blockquote type="cite" class=""> size = sizeof(type)<br class=""> stride = strideof(type)<br class=""> alignment = alignof(type)<br class=""> }<br class="">}<br class=""></blockquote><br class="">These are all possible syntaxes, but I think #3 is best:<br class=""><br class="">1. MemoryLayout(Int.self).size<br class="">2. memoryLayout(Int.self).size<br class="">3. MemoryLayout<Int>.size<br class=""><br class="">I don't see any advantage of #1 over #2, and there's no need at all to<br class="">define a new nominal type if we only want #2:<br class=""><br class=""> func memoryLayout<T>(_ T.type) -> (size: Int, stride: Int, alignment: Int) {<br class=""> // implementation<br class=""> }<br class=""><br class=""><blockquote type="cite" class="">Nate<br class=""><br class=""><blockquote type="cite" class="">On Jun 5, 2016, at 7:54 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">on Thu Jun 02 2016, John McCall <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>>> wrote:<br class=""><br class=""><blockquote type="cite" class="">On Jun 2, 2016, at 1:43 PM, Russ Bishop <<a href="mailto:xenadu@gmail.com" class="">xenadu@gmail.com</a>> wrote:<br class=""><br class="">On Jun 2, 2016, at 11:30 AM, John McCall via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>><br class="">wrote:<br class=""><br 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.<br class=""><br class="">John.<br class=""><br class="">I agree; in fact why aren’t these properties on the type itself? The type is what matters; why can’t the type just tell me it’s size? <br class="">Having free functions or magic operators seems to be another holdover from C. <br class=""><br class="">Int.size<br class="">Int.alignment<br class="">Int.spacing<br class=""><br class="">let x: Any = 5<br class="">type(of: x).size<br class=""><br class="">The compiler should be able to statically know the first three values and inline them. The second is discovering the size dynamically.<br class=""><br class="">Two reasons. The first is that this is a user-extensible namespace via<br class="">static members, so it's somewhat unfortunate to pollute it with names<br class="">from the library. The second is that there's currently no language<br class="">mechanism for adding a static member to every type, so this would have<br class="">to be built-in. <br class=""></blockquote><br class="">More fundamental reasons:<br class=""><br class=""><br class="">* `Array<Int>.size` is easily misinterpreted. The identifier<br class=""> `MemoryLayout` was suggested in order to set the proper mental context<br class=""> at the use site.<br class=""><br class="">* I don't want “size,” “alignment,” and “spacing” appearing in the<br class=""> code-completion list for every type. <br class=""><br class="">* I can easily imagine users wanting to use static properties by these<br class=""> names for their own types, with completely different meaning.<br class=""><br class=""><blockquote type="cite" class="">But I agree that in the abstract a static property would be<br class="">preferable.<br class=""><br class="">John.<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a> <<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a>><br class=""><br class=""></blockquote><br class="">-- <br class="">-Dave<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a> <<a href="mailto:swift-evolution@swift.org" class="">mailto:swift-evolution@swift.org</a>><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a> <<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a>><br class=""></blockquote></blockquote><br class="">-- <br class="">Dave<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></body></html>