> On Sep 5, 2017, at 11:59 AM, Jordan Rose via swift-dev <swift-dev@swift.org> > 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 swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev