> On Sep 5, 2017, at 11:59 AM, Jordan Rose via swift-dev <[email protected]>
> wrote:
>
> 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?
This is going against the grain, but I think we should order by name and
therefore allow reordering, but not renaming. If an API is public, renaming is
obviously going to be source-breaking and could easily be ABI-breaking; I don't
think it's that hard to explain that renaming can also be ABI-breaking when
you've declared your type's layout is part of your module's ABI. And we can
always introduce a renaming attribute that causes the property to be laid out
and linked by its old name:
@fixedContents struct Foo {
@renamed(from: x, in: iOS 14)
var xCount: Int
@renamed(from: y, in: iOS 14)
var yAverage: Double
@renamed(from: z, in: iOS 14)
var zIdentifier: String
}
We could detect properties appearing and disappearing in our compatibility
checker tool and help people add the missing attributes. We could provide
fix-its for renames of public APIs. We could use the name `_` to allow a type
to reserve space for future expansion, or remove a property that is no longer
used. We could add a syntax to `@renamed` that permits the space used by old
properties to be subdivided into new ones. And we can always add ways to
manually control the layout of a type in future versions of Swift; they would
be usable both with and without `@fixedContents`, and would be orthogonal to
`@fixedContents`.
(In theory, we could do this with `@available`, but its current renaming
support requires a dummy declaration.)
As for the keyword…maybe `public(layout)` or `public(storage)`? People are
familiar with the idea that you have to be careful when you change something
that's public, so it wouldn't be surprising that a type with a public layout
would be sensitive to changes to its memory layout.
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-dev
