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

[Slava Pestov]

> On Sep 6, 2017, at 7:57 PM, Brent Royal-Gordon via swift-dev <swift-dev at swift.org> wrote:
> 
>> On Sep 5, 2017, at 11:59 AM, Jordan Rose via swift-dev <swift-dev at swift.org <mailto: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.

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).

> 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).

Slava

> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

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