> On Aug 17, 2016, at 11:28 AM, Russ Bishop via swift-evolution
> <[email protected]> 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.
>
> 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?
Property behaviors could conceivably get you at least some of the way here. You
could do something like this:
protocol ManualLayout {
associatedtype Storage
var storage: Storage
}
struct Foo: ManualLayout {
var storage: [4 x Int32] // give me 16 bytes of 32-bit-aligned storage
var [offset(0)] foo: Int32
var [offset(5)] bar: Int32
var [offset(10)] bas: Int32
}
-Joe
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
