No problem, I'll put it on the back burner for the time being. Russ
> On Aug 19, 2016, at 12:50 PM, Joe Groff <[email protected]> wrote: > > >> 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
