> On Aug 17, 2016, at 11:28 AM, Russ Bishop via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> I wanted to gauge the interest in supporting explicit struct layout and
> alignment.
>
> The general idea would be to support attributes to create packed structs and
> set alignment. It will be critical for certain kinds of interop and systems
> programming in pure Swift. I don’t know about you but I want to write a
> kernel module in Swift someday :) I’m bringing it up because it probably
> affects ABI stability and resilience and so meets the requirements for Swift
> 4 phase 1.
Explicit layout matters for the ABI once the feature exists, but it seems
purely additive, i.e. out of scope for Swift 4 phase 1. You can ship without
any explicit layout support and add it later without impacting code that ships
before the feature exists.
Mark
>
> Hopefully this could be a jumping-off point for further discussion. If the
> core team doesn’t think this affects ABI stability then we can postpone
> discussing it until Swift 4 phase 1 wraps up.
>
>
> @layout(style: auto, alignment: natural)
>
> enum LayoutStyle {
> /// Compiler is free to order the fields as it likes
> case automatic
> /// Places a struct's members in source order
> case sequential
> /// Requires each member to have an @order attribute
> case ordered
> /// Requires each member to have an @offset attribute
> case explicit
> }
>
> Only structs with certain @layout attributes would be exportable to non-Swift
> languages (assuming such support is added at some point). A struct defined
> with ordered or explicit layout and as resilient could possibly avoid
> indirect access to members since the ABI contract guarantees the location of
> each member.
>
>
> enum Alignment {
> /// Compiler decides
> case natural
> /// Align as if the natural alignment were specified bytes
> case bytes(Int)
> }
>
>
>
> @order(<int>)
>
> Specifies the order of the member in memory. Order must start at zero and
> increase monotonically without gaps. This makes accidental changes to the
> ordering errors.
>
>
>
> @offset(<int>)
>
> Specifies the offset from the start of the struct where this member should be
> placed. The size of the struct becomes the highest offset plus the size of
> the member with that offset.
>
> It is an open question whether overlapping alignment should be allowed. If it
> is allowed I’d propose that for any set of members overlapping all of the
> members must be entirely contained within the largest overlapping member (I’m
> thinking of C-style unions when the struct format is imposed by something
> outside your control).
>
>
>
> Thoughts?
>
> Russ
>
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
