<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"><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 class=""><br class=""></div><div class="">On Jun 2, 2016, at 16:57, Sean Heber via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><span class="">This might be silly, but what if there were a struct with all of the relevant fields (not sure what the best name would be):</span><br class=""><span class=""></span><br class=""><span class="">struct MemoryLayout {</span><br class=""><span class=""> let size: Int</span><br class=""><span class=""> let alignment: Int</span><br class=""><span class=""> let stride: Int</span><br class=""><span class=""> // etc</span><br class=""><span class="">}</span><br class=""><span class=""></span><br class=""><span class="">Then you’d only maybe need two functions:</span><br class=""><span class=""></span><br class=""><span class="">memoryLayout(of:) and memoryLayout(ofType:)</span><br class=""><span class=""></span><br class=""><span class="">Or perhaps just a single property on all types named “memoryLayout” (or whatever) that returns the MemoryLayout struct:</span><br class=""><span class=""></span><br class=""><span class="">Int.memory.size</span><br class=""><span class="">type(of: 42).memoryLayout.size</span><br class=""><span class="">// etc</span><br class=""><span class=""></span><br class=""><span class="">Or just a single property on UnsafePointer if we went that route..</span><br class=""><span class=""></span><br class=""><span class="">It seems like this sort of approach would keep namespace pollution down, at least?</span><br class=""></div></blockquote>I was about to suggest the something very much like that.<div class=""><br class=""></div><div class="">In addition to reducing namespace "pollution", I like that it kinda moves implementation and target-level details into their own little "type terrarium"... I might suggest renaming "MemoryLayout" to something like "ImplementationDetails". The latter seems more to-the-point, but, aside from endianness, I'm not sure if any such details wouldn't fall under the umbrella of "memory layout" anyway.</div><div class=""><br class=""></div><div class="">Hmm… If <i class="">all</i> the details of a type’s memory layout can be represented in this “MemoryLayout" type, could we use it to manually construct a type "in-code" instead of going through the compiler? I’m not sure it works "that way”… Nor am I sure what the point would be, but it might be handy if you have clever idea that the compiler can’t understand.</div><div class=""><br class=""></div><div class="">I clearly shouldn’t be up this early.</div><div class=""><br class=""></div><div class="">- Dave Sweeris</div></body></html>