[swift-dev] What can you change in a fixed-contents struct?

[Jordan Rose]

> On Sep 5, 2017, at 15:08, Slava Pestov via swift-dev <swift-dev at swift.org> wrote:
> 
>> 
>> On Sep 5, 2017, at 2:48 PM, Thomas Roughton via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>> 
>> 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.
> 
> @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.
> 
> 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.

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 control layout.

We did 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.

Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170905/743f6765/attachment.html>