<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 5, 2017, at 9:41 PM, Slava Pestov via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Sep 5, 2017, at 6:37 PM, Nevin Brackett-Rozinsky via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 5, 2017 at 6:08 PM, Slava Pestov via swift-dev <span dir="ltr" class=""><<a href="mailto:swift-dev@swift.org" target="_blank" class="">swift-dev@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=""><div class=""><div class="">We expect that “define your struct in C” is still the way to go for layout compatibility with other languages and systems.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Are there plans (however tentative) to eventually make it possible to specify the exact memory layout of a struct in Swift?</div></div></div></div></div></blockquote><div class=""><br class=""></div>It’s not clear what ‘exact memory layout’ means. In C, you don’t get to specify the exact layout either — there are rules around alignment and padding and some non-standard attributes for controlling them, but that’s not quite the same thing.</div><div class=""><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">It seems like something we will have to tackle in order for Swift to become a serious systems-level programming language.</div></div></div></div></blockquote><div class=""><br class=""></div>We do plan on documenting Swift’s struct (and tuple) layout algorithms as part of ABI stability, because we will need to freeze them (at least for types that cross resilience boundaries) to actually have a stable ABI. So you could, with knowledge of the layout algorithm, define a struct and make assumptions about it’s layout in memory, based on your knowledge of the algorithm as it is implemented in the version of Swift you are using. Not quite the same as explicitly specifying a layout, though.</div></div></div></blockquote><div><br class=""></div>To be exact, we need to be able to universally agree on the layout algorithm used for a specific struct. That doesn't require us to only have one such algorithm; we can improve the struct layout algorithm in future releases as long as we have some way of ensuring that previously-fragile structs don't use the improved parts. Since Swift libraries will need to have a minimum Swift "deployment target", the most obvious way to pick an algorithm woulds simply be to use the layout algorithm from the library's minimum Swift target version at the time when the struct was first made fragile. That should be easy enough to record in a library's ABI description.</div><div><br class=""></div><div>We could do something similar with tuples by finding the minimum target of all the element types, but the complexity would be less localized. There's merit to keeping the tuple layout algorithm simple, especially if it lets us make stronger memory-model statements about tuple elements. We also have a very straightforward answer to someone concerned about tuple memory layout efficient: just use a struct.</div><div><br class=""></div><div>John.</div></body></html>