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
https://lists.swift.org/mailman/listinfo/swift-dev
