Ability to pack, order and align certain types of Structs (like in C)

To the community:

Neither am I a compiler/language design expert nor have I previously
written a proposal to that effect, so I apologise if I have
trivialised the matter especially with regard to other parts of Swift
or if some of it already exists. I am also aware that what I've
proposed herein maybe possible through alternate means. However, the
aim of this is to make it a first-class feature in Swift itself. For
those unfamiliar with what is being requested, please see [2], [5] and [8].

I have also filed this as a language feature request at [7].

Proposal:
* As a Swift language user, I would like the ability to specify
packing, order and alignment for certain type of Structs and their
members.
* The characteristics requested are: packing, padding, ordering and
byte-level alignment of Struct elements
* All the requested characteristics would work similarly to the way they do in C
* Ideally, this should be achieved in a way that makes it simple to
use with appropriate syntactic sugar

Potential Preconditions (for the feature):
* Only Structs with certain, basic named types such as Int, UInt, etc.?
* Allow Enums and Tuples as well, so long as only basic named types
are allowed within them?
* No other nested types unless they meet the above criteria?
* Type aliased names can be used within the Struct so long as they
meet the above preconditions?

Alternatives:
* Augment and integrate something similar to [1], which mimics the
Python struct module [6]
* Recommend interfacing with C, for any language user who requires the
aforementioned characteristics; but this route would devoid the
language of self-sufficiency from a systems programming aspect.

Ultimately even if the above is deemed totally undesirable (I hope
not), at the very least, I hope it stirs discussion about being able
to use Swift as a systems programming language and how we could
possibly move toward that direction.

Thanks for your consideration!

For reference:

[1] https://github.com/nst/BinUtils/
[2] http://stackoverflow.com/questions/24139149/how-do-i-create-a-packed-data-structure-in-swift
[3] http://stackoverflow.com/questions/13688625/how-to-declare-packed-struct-without-padding-for-llvm
[4] https://llvm.org/svn/llvm-project/cfe/branches/eh-experiment/test/Sema/struct-packed-align.c
[5] http://www.catb.org/esr/structure-packing/
[6] https://docs.python.org/3/library/struct.html
[7] https://bugs.swift.org/browse/SR-1134
[8] https://mikeash.com/pyblog/friday-qa-2014-08-01-exploring-swift-memory-layout-part-ii.html

Yes, this would be a great thing to have, but it requires significant design and implementation work, so I’m afraid it is out of scope for Swift 3. In the meantime, a lame workaround is that you can define your struct in C and import it. Swift will honor the layout of the C type.

-Chris

···

On Apr 7, 2016, at 12:28 PM, hitstergtd+swiftevo--- via swift-evolution <swift-evolution@swift.org> wrote:

To the community:

Neither am I a compiler/language design expert nor have I previously
written a proposal to that effect, so I apologise if I have
trivialised the matter especially with regard to other parts of Swift
or if some of it already exists. I am also aware that what I've
proposed herein maybe possible through alternate means. However, the
aim of this is to make it a first-class feature in Swift itself. For
those unfamiliar with what is being requested, please see [2], [5] and [8].

I have also filed this as a language feature request at [7].

Chris,

Thanks for supporting it in principle. I understand that it is out of
scope for Swift 3 and that using C is one of the only decent
workarounds at the moment.

However, since you concur with what is being requested, would it be OK to:

(a) Draft a summary proposal and commit it to the swift-evolution@
repository, perhaps under "Other Proposals" or "Post v3"? and/or
(b) Add some notes under docs/, perhaps in docs/LibraryEvolution.rst
regarding this topic?

I am uncertain as to what happens after Swift 3 since there don't seem
to be any guidelines for that; hopefully the above would ensure that
it isn't forgotten. :slight_smile:

···

On 8 April 2016 at 07:01, Chris Lattner <clattner@apple.com> wrote:

On Apr 7, 2016, at 12:28 PM, hitstergtd+swiftevo--- via swift-evolution <swift-evolution@swift.org> wrote:

To the community:

Neither am I a compiler/language design expert nor have I previously
written a proposal to that effect, so I apologise if I have
trivialised the matter especially with regard to other parts of Swift
or if some of it already exists. I am also aware that what I've
proposed herein maybe possible through alternate means. However, the
aim of this is to make it a first-class feature in Swift itself. For
those unfamiliar with what is being requested, please see [2], [5] and [8].

I have also filed this as a language feature request at [7].

Yes, this would be a great thing to have, but it requires significant design and implementation work, so I’m afraid it is out of scope for Swift 3. In the meantime, a lame workaround is that you can define your struct in C and import it. Swift will honor the layout of the C type.

-Chris

Chris,

Thanks for supporting it in principle. I understand that it is out of
scope for Swift 3 and that using C is one of the only decent
workarounds at the moment.

However, since you concur with what is being requested, would it be OK to:

(a) Draft a summary proposal and commit it to the swift-evolution@
repository, perhaps under "Other Proposals" or "Post v3"? and/or
(b) Add some notes under docs/, perhaps in docs/LibraryEvolution.rst
regarding this topic?

I am uncertain as to what happens after Swift 3 since there doesn't seem
to be any guidelines for that; hopefully the above would ensure that
it isn't forgotten. :slight_smile:

···

On 8 April 2016 at 07:01, Chris Lattner <clattner@apple.com> wrote:

On Apr 7, 2016, at 12:28 PM, hitstergtd+swiftevo--- via swift-evolution <swift-evolution@swift.org> wrote:

To the community:

Neither am I a compiler/language design expert nor have I previously
written a proposal to that effect, so I apologise if I have
trivialised the matter especially with regard to other parts of Swift
or if some of it already exists. I am also aware that what I've
proposed herein maybe possible through alternate means. However, the
aim of this is to make it a first-class feature in Swift itself. For
those unfamiliar with what is being requested, please see [2], [5] and [8].

I have also filed this as a language feature request at [7].

Yes, this would be a great thing to have, but it requires significant design and implementation work, so I’m afraid it is out of scope for Swift 3. In the meantime, a lame workaround is that you can define your struct in C and import it. Swift will honor the layout of the C type.

-Chris

We don’t have a hard rule against discussing things beyond swift 3, but we generally discourage it. There is too much important stuff going on in the swift 3 timeframe as it is, and the distraction factor can be very high. I’d suggest filing a bug in bugs.swift.org, and you can work on a sketch of a proposal there. Thanks!

-Chris

···

On Apr 8, 2016, at 8:02 AM, hitstergtd+swiftevo--- via swift-evolution <swift-evolution@swift.org> wrote:

Chris,

Thanks for supporting it in principle. I understand that it is out of
scope for Swift 3 and that using C is one of the only decent
workarounds at the moment.

However, since you concur with what is being requested, would it be OK to:

(a) Draft a summary proposal and commit it to the swift-evolution@
repository, perhaps under "Other Proposals" or "Post v3"? and/or
(b) Add some notes under docs/, perhaps in docs/LibraryEvolution.rst
regarding this topic?

Chris,

Thanks. The distraction factor makes sense. I will update SR-1134 as
discussed and mark it as post Swift v3.

···

On 9 April 2016 at 14:13, Chris Lattner <clattner@apple.com> wrote:

On Apr 8, 2016, at 8:02 AM, hitstergtd+swiftevo--- via swift-evolution > <swift-evolution@swift.org> wrote:

Chris,

Thanks for supporting it in principle. I understand that it is out of
scope for Swift 3 and that using C is one of the only decent
workarounds at the moment.

However, since you concur with what is being requested, would it be OK to:

(a) Draft a summary proposal and commit it to the swift-evolution@
repository, perhaps under "Other Proposals" or "Post v3"? and/or
(b) Add some notes under docs/, perhaps in docs/LibraryEvolution.rst
regarding this topic?

We don’t have a hard rule against discussing things beyond swift 3, but we
generally discourage it. There is too much important stuff going on in the
swift 3 timeframe as it is, and the distraction factor can be very high.
I’d suggest filing a bug in bugs.swift.org, and you can work on a sketch of
a proposal there. Thanks!

-Chris

Thanks!

-Chris

···

On Apr 9, 2016, at 9:47 AM, hitstergtd+swiftevo@gmail.com wrote:

Chris,

Thanks. The distraction factor makes sense. I will update SR-1134 as
discussed and mark it as post Swift v3.

On 9 April 2016 at 14:13, Chris Lattner <clattner@apple.com> wrote:

On Apr 8, 2016, at 8:02 AM, hitstergtd+swiftevo--- via swift-evolution >> <swift-evolution@swift.org> wrote:

Chris,

Thanks for supporting it in principle. I understand that it is out of
scope for Swift 3 and that using C is one of the only decent
workarounds at the moment.

However, since you concur with what is being requested, would it be OK to:

(a) Draft a summary proposal and commit it to the swift-evolution@
repository, perhaps under "Other Proposals" or "Post v3"? and/or
(b) Add some notes under docs/, perhaps in docs/LibraryEvolution.rst
regarding this topic?

We don’t have a hard rule against discussing things beyond swift 3, but we
generally discourage it. There is too much important stuff going on in the
swift 3 timeframe as it is, and the distraction factor can be very high.
I’d suggest filing a bug in bugs.swift.org, and you can work on a sketch of
a proposal there. Thanks!

-Chris

Hi guys,

How about returning to this discussion again? :slight_smile:

Packing is a good thing to work with low level communication protocols.
This would be great to have it.

1 Like

we still have the problem where swift (read: the processor) can’t read misaligned values so the “correct” solution would be to declare opaque storage (we don’t have this either, but a long tuple would probably suffice) and then do the appropriate shifts in computed properties. as for the ordering of the fields there’s @_fixed_layout or something for that

I think that a set of annotations allowing one to precisely specify the layout of a struct would be a useful addition. We often hear this request because someone wants to write a struct to match an on-disk or on-the-wire buffer format. If someone gets the process started, I suspect that there are a number of people interested in helping with such a design.

3 Likes