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