> On Sep 6, 2017, at 7:57 PM, Brent Royal-Gordon via swift-dev > <swift-dev@swift.org> wrote: > >> On Sep 5, 2017, at 11:59 AM, Jordan Rose via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@swift.org>> wrote: >> >> Now, we don't plan to stick to C's layout for structs, even fixed-contents >> structs. We'd really like users to not worry about manually packing things >> into trailing alignment space. But we still need a way to lay out fields >> consistently; if you have two stored properties with the same type, one of >> them has to go first. There are two ways to do this: sort by name, and sort >> by declaration order. That means we can either allow reordering or allow >> renaming, but not both. Which do people think is more important? > > This is going against the grain, but I think we should order by name and > therefore allow reordering, but not renaming. If an API is public, renaming > is obviously going to be source-breaking and could easily be ABI-breaking; I > don't think it's that hard to explain that renaming can also be ABI-breaking > when you've declared your type's layout is part of your module's ABI.
However, @fixedContents structs can also contain private stored properties. Renaming a private property is not source-breaking (but if we sort by name when performing layout, it will be ABI breaking). > As for the keyword…maybe `public(layout)` or `public(storage)`? People are > familiar with the idea that you have to be careful when you change something > that's public, so it wouldn't be surprising that a type with a public layout > would be sensitive to changes to its memory layout. I’m hesitant to use a keyword rather than an @attribute for this, because (for the most part) attributes don’t change the language semantics of a declaration, only its implementation (of course there are exceptions, like @objc which introduces restrictions, etc). Slava > > -- > Brent Royal-Gordon > Architechies > > _______________________________________________ > swift-dev mailing list > swift-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-dev
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
