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

[Brent Royal-Gordon]

> On Sep 6, 2017, at 9:52 PM, Slava Pestov <spestov at apple.com> wrote:
> 
>> On Sep 6, 2017, at 7:57 PM, Brent Royal-Gordon via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>> 
>> 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.
> 
> However, @fixedContents structs can also contain private stored properties. Renaming a private property is not source-breaking (but if we sort by name when performing layout, it will be ABI breaking).

I understand that. I think this is explicable if you think of `@fixedContents` as intentionally compromising the privacy of private stored properties. And I think that attaching this feature to the `public` keyword would help to encourage that mindset.

Another way to encourage a "don't change this" mindset would be to use a word like "frozen" in the attribute/keyword. It wouldn't be surprising if you caused problems by changing something you've "frozen". Example:

	@frozen(var) public struct Foo { … }
	@frozen(case) public enum Bar { … }

>> 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.
> 
> I’m hesitant to use a keyword rather than an @attribute for this, because (for the most part) attributes don’t change the language semantics of a declaration, only its implementation (of course there are exceptions, like @objc which introduces restrictions, etc).

I feel like I must not understand what you mean by semantics vs. implementation, because most of the attributes I can think of handle things I would consider to be "semantics". `@escaping`, `@autoclosure`, `@available`, `@discardableResult`, etc.

-- 
Brent Royal-Gordon
Architechies

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170909/3ed6990c/attachment.html>