<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Sep 5, 2017, at 15:52, Greg Parker <<a href="mailto:gparker@apple.com" class="">gparker@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Sep 5, 2017, at 11:59 AM, Jordan Rose via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hey, all. In preparation for the several proposals we have to come this year, I <a href="https://github.com/apple/swift/pull/11742" class="">cleaned up docs/LibraryEvolution.rst</a> 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?<div class=""><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">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.<br class=""></blockquote><div class=""><br class=""></div>Interestingly, this means that you <i class="">can</i> 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.</div><div class=""><br class=""></div><div class="">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, <i class="">one</i> of them has to go first. There are two ways to do this: sort by name, and sort by declaration order. <b class="">That means we can <i class="">either</i> allow reordering <i class="">or</i> allow renaming, but not both</b>. Which do people think is more important?</div><div class=""><br class=""></div><div class="">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 <i class="">ABI</i>.</div></div></div></div></blockquote><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><br class=""></div><div>Good point. One slight difference here is that if you <i class="">do</i> 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 <i class="">any</i> fields, even the non-public ones, in order to properly implement the value copy operation.</div><div><br class=""></div><div>Jordan</div><br class=""></body></html>