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

[John McCall]

> On Sep 5, 2017, at 9:41 PM, Slava Pestov via swift-dev <swift-dev at swift.org> wrote:
> 
> 
>> On Sep 5, 2017, at 6:37 PM, Nevin Brackett-Rozinsky via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>> 
>> On Tue, Sep 5, 2017 at 6:08 PM, Slava Pestov via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>> We expect that “define your struct in C” is still the way to go for layout compatibility with other languages and systems.
>> 
>> Are there plans (however tentative) to eventually make it possible to specify the exact memory layout of a struct in Swift?
> 
> 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.
> 
>> It seems like something we will have to tackle in order for Swift to become a serious systems-level programming language.
> 
> 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.

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.

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.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170906/c7ff1d2f/attachment.html>