> On Sep 6, 2017, at 9:52 PM, Slava Pestov <spes...@apple.com> wrote:
>
>> On Sep 6, 2017, at 7:57 PM, Brent Royal-Gordon via swift-dev
>> <swift-dev@swift.org <mailto:swift-dev@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
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
