<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 5, 2017, at 15:08, 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=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Sep 5, 2017, at 2:48 PM, Thomas Roughton 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 class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class="">Having an explicit @abi annotation could also go some way to addressing the issue of manual layout with structs. I’m primarily thinking of graphics contexts, wherein you need to declare e.g. a struct with vertex layout, and then that needs to be specified when passed to the GPU. The current solution is to declare in C code and import into Swift, which is cumbersome; having @fixedContents structs be the method of choice when a deterministic layout is needed seems to make sense. If combined with a hypothetical MemoryLayout<Type>.offsetOf(property) Swift would, I think, meet that need.</div></div></div></blockquote><div class=""><br class=""></div><div class="">@fixedContents is not meant for this purpose. We don’t want to guarantee that the layout matches what you would write in C. Of course once the ABI is stable, the layout of a fixed contents struct will be fixed — it just might not be what your GPU expects.</div><div class=""><br class=""></div><div class="">So perhaps @fixedContents is not the best name. 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><br class=""></div><div>Right. The hypothetical 'abi' attribute that Dave mentions is "just" a stable identifier that can be used instead of "name" or "declaration order", rather than something that can <i class="">control</i> layout.</div><div><br class=""></div><div>We <i class="">did</i> say that the layout of a tuple that contains C-compatible types will always match the layout of an equivalent C struct, so if you need a guaranteed layout in Swift you can do it that way too. But Slava's right that it's probably easiest to just define your struct in C.</div><div><br class=""></div><div>Jordan</div><br class=""></body></html>