Ah, now that I see the CGPoint example, I understand. Thanks! Ya, the “hard” user-experience model I brought up feels wrong for CGPoint, etc. (For non-Apple people, CGPoint is a struct of two doubles on 64-bit machines add two floats on 32-bit machines.)
It wasn’t obvious to me from context that @fixedContents wasn’t / isn’t for people trying to design a comprehensive ABI (disk, wire, etc), but just the machine specific in memory ABI. I wish the name was better, but nothing better seems obvious. (“@inMemoryABI”?) Dave > On Sep 6, 2017, at 13:11, Jordan Rose <jordan_r...@apple.com> wrote: > > I'd be okay with allowing the ABI attributes to control ordering, but I would > definitely not require them on every fixed-contents struct. We hope making a > struct fixed-contents isn't something people have to do too often, but we > don't want to drop them all the way into "hard" land when they do it. That > is, "CGPoint" can't already be "hard mode". > > Jordan > > >> On Sep 6, 2017, at 05:13, David Zarzycki <zarzy...@icloud.com >> <mailto:zarzy...@icloud.com>> wrote: >> >> Hi Jordan, >> >> I really doubt that “belt and suspenders” ABI attributes would drive people >> to C, but reasonable people can certainly disagree on that. >> >> Bertrand, when he was at Apple, used to say that “easy things should be >> easy, and hard things should be possible”. >> >> I think ABI related attributes fall into the latter category. In particular, >> I think that trying to make ABI attributes too convenient only does >> programmers a disservice in the long run because most programmers aren't >> experts, and the cost of ignorance is huge when trying to do ABI design. >> >> With these thoughts in mind, I think that is reasonable for the language to >> say: “If you want explicit control over a dimension of ABI decisions, then >> you must deal with all of the associated complexity. Here is a pointer to >> the documentation on dimension X that you were/are trying to explicitly >> manage. If that is ’too hard’ for you, then you probably shouldn’t be >> locking down this dimension of complexity yet.” >> >> Dave >> >>> On Sep 5, 2017, at 20:11, Jordan Rose <jordan_r...@apple.com >>> <mailto:jordan_r...@apple.com>> wrote: >>> >>> Hm. This is definitely an option, but I don't think it's really an >>> acceptable user experience. This feels like it'll drive people all the way >>> to declaring their types in C because Swift makes it too hard. >>> >>> We do expect to have a tool to diff old and new modules at some point, but >>> we could do something even simpler here: make a public symbol with the >>> struct's layout in its name. That way, even 'nm' can tell if the symbol >>> disappears. (Of course, public symbols do have a small cost, since this >>> might not actually be the best idea.) >>> >>> Another idea would be to restrict @fixedContents to require that all stored >>> properties appear contiguously in the struct, possibly even pinned to the >>> top or bottom, to indicate that order's not completely arbitrary. Again, >>> that's just an improvement, not full protection. >>> >>> Jordan >>> >>> >>>> On Sep 5, 2017, at 13:00, David Zarzycki <zarzy...@icloud.com >>>> <mailto:zarzy...@icloud.com>> wrote: >>>> >>>> Hi Jordan, >>>> >>>> Thanks for thinking about this. For whatever it may be worth, I’m >>>> concerned about 1) the ability to reorder declarations and 2) the >>>> “either/or” nature of this proposal. >>>> >>>> First, reordering: The ability to reorder declarations is deeply ingrained >>>> into the subconsciousness of Swift programmers and for good reasons. I >>>> think adding localized declaration order sensitivity is likely to be very >>>> brittle and regrettable in the long run. I also think this problem is made >>>> worse by having a type declaration context attribute because it can easily >>>> get lost in the noise of nontrivial declarations. The net result is that >>>> people will frequently forget about local order sensitivity. Yes, the >>>> compiler can engage in heroics and compare the previous module ABI and the >>>> new module ABI for conflicts, but that seems risky, complex, slow, and >>>> differently error prone. >>>> >>>> Second, the “either/or” nature of this proposal: What do you think about a >>>> lightweight “belt and suspenders” solution whereby @fixedContents requires >>>> that stored properties be lightly annotated with their layout order? For >>>> example: >>>> >>>> @fixedContents(3) struct Foo { >>>> @abi(0) var x: Int >>>> func a() { >>>> // a thousand lines of ABI layout distraction >>>> } >>>> @abi(1) var y: Double >>>> func b() { >>>> // another thousand lines of ABI layout distraction >>>> } >>>> @abi(2) var z: String >>>> } >>>> >>>> That would enable both renaming and reordering, would it not? This >>>> approach would also aid the compiler in quickly detecting hastily >>>> added/deleted declarations too because the count of @abi([0-9]+) >>>> declarations wouldn’t match the number passed to @fixedContents. >>>> >>>> Dave >>>> >>>> >>>> >>>>> On Sep 5, 2017, at 14:59, 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 theory we could also make different decisions for public and >>>>> non-public fields, because it's much less likely to want to change the >>>>> name of a public property. But you could do it without breaking source >>>>> compatibility by introducing a computed property at the same time as you >>>>> do the renaming. It's up to us whether that should break binary >>>>> compatibility or not.) >>>>> >>>>> >>>>> Note that because the layout algorithm isn't public, Swift isn't going to >>>>> allow the thing from C where you have an existing field and you split it >>>>> into two smaller fields. You can use computed properties for that >>>>> instead. (Strictly speaking this probably isn't even good C because the >>>>> fields in your struct can affect by-value calling conventions.) >>>>> >>>>> >>>>> By the way, I'm putting this on swift-dev because we're nowhere near a >>>>> proposal and I want to keep the discussion narrow for now, but of course >>>>> this point will be called out when the fixed-contents attribute—whatever >>>>> its final form—goes to swift-evolution for a proper review. >>>>> >>>>> Thanks! >>>>> Jordan >>>>> _______________________________________________ >>>>> swift-dev mailing list >>>>> swift-dev@swift.org <mailto:swift-dev@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-dev >>>>> <https://lists.swift.org/mailman/listinfo/swift-dev> >>>> >>> >> >
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
