> On Sep 6, 2017, at 11:09 AM, David Zarzycki via swift-dev > <swift-dev@swift.org> wrote: > > I see. Would “@fixedSize” or “@abi(size)” be better names? In other words, > the developer promises that whatever size the struct is now, it will be that > way forever? > > Also, wouldn’t the Pair<A> example below require that ‘A’ also be > @fixedContents? Otherwise what does @fixedContents mean if the elements > aren’t fixed?
We don’t require ‘transitive’ fragility with generic value types containing other types. Otherwise, Optional<T> would have to require that T is fixedContents, which is too restrictive. Slava > > Dave > > >> On Sep 6, 2017, at 13:44, Jordan Rose <jordan_r...@apple.com >> <mailto:jordan_r...@apple.com>> wrote: >> >> I don't think that's the right way to think about it either. It's purely an >> optimization tool to say "I won't add anything else to this struct", which >> means the compiler can avoid indirection when manipulating the struct across >> module boundaries. We could implement it with dynamic offset symbols and >> still see some benefit, but in this case we really ought to be able to get >> all the way to C-level performance. >> >> The name hasn't been formalized; this will all go through swift-evolution at >> some point. We thought about "fixed-layout" in the past, but that doesn't >> have the right connotations for something like Pair: >> >> @fixedContents >> public struct Pair<A> { >> public var first: A >> public var second: A >> public init(first: A, second: A) { … } >> } >> >> This has known properties, but the layout depends on the generic argument, >> and if the generic argument is itself a type with unknown size then the >> actual layout won't be known until runtime. >> >> Jordan >> >> >>> On Sep 6, 2017, at 10:40, David Zarzycki <zarzy...@icloud.com >>> <mailto:zarzy...@icloud.com>> wrote: >>> >>> 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 >>>> <mailto: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
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
