[swift-dev] What can you change in a fixed-contents struct?

[Brent Royal-Gordon]

> On Sep 5, 2017, at 11:59 AM, Jordan Rose via swift-dev <swift-dev at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170906/7a7f4d56/attachment.html>