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?
Dave
> On Sep 6, 2017, at 13:44, Jordan Rose <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
