> On Sep 5, 2017, at 15:52, Greg Parker <gpar...@apple.com> wrote: > > >> On Sep 5, 2017, at 11:59 AM, Jordan Rose via swift-dev <swift-dev@swift.org >> <mailto:swift-dev@swift.org>> wrote: >> >> Hey, all. In preparation for the several proposals we have to come this >> year, I cleaned up docs/LibraryEvolution.rst >> <https://github.com/apple/swift/pull/11742> a little bit based on what's >> changed in Swift 4. This is mostly just mentioning things about generic >> subscripts, but there is one issue that I remember John bringing up some >> time in this past year: once you've made a struct fixed-contents, what can >> you change about its stored properties? >> >>> To opt out of this flexibility, a struct may be marked '@fixedContents'. >>> This promises that no stored properties will be added to or removed from >>> the struct, even non-public ones. >> >> Interestingly, this means that you can have non-public members of a >> fixed-contents struct. This is actually pretty sensible: it's the equivalent >> of a C++ class with non-public fields but a defaulted, inlinable copy >> constructor. Any inlinable members can access these properties directly as >> well; it's just outsiders that can't see them. But if inlinable code can >> reference these things, and if we really want them to be fast, that means >> they have to have a known offset at compile-time. >> >> 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? >> >> At the moment I'm inclined to go with "allow renaming" just because that's >> what C does. It's not great because you're allowed to reorder nearly >> everything else in the language, but there's a "least surprise" principle >> here that I think is still useful. It'd be surprising for the name of a >> non-public property to affect your library's ABI. > > In a somewhat similar semantic situation, Objective-C non-fragile ivars chose > to allow reordering and disallow renaming. One reason is that we wanted to > prevent accidental ABI breaks as best we could. The assumption was that a > name change is probably deliberate, but an order change is likely to be an > accidental effect of source code rearrangement. In addition, erroneous name > changes are more likely to be caught downstream (for example when clients > fail to build because they didn't change their use of the name), but > erroneous order changes are less likely to be caught later. > > The goal of preventing accidental ABI breaks becomes less important if Swift > gets good ABI-diffing tools that can help catch errors after they are > introduced. ObjC had no effective way to verify that your current ABI matched > your previously-published ABI.
Good point. One slight difference here is that if you do break the ABI with non-fragile ivars, it only matters if there are direct references to them from outside the library. For @fixedContents structs, the client may have direct references to any fields, even the non-public ones, in order to properly implement the value copy operation. Jordan
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
