<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Sep 5, 2017, at 11:59 AM, Jordan Rose via swift-dev &lt;<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">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,<span class="Apple-converted-space">&nbsp;</span><i class="">one</i>&nbsp;of them has to go first. There are two ways to do this: sort by name, and sort by declaration order.<span class="Apple-converted-space">&nbsp;</span><b class="">That means we can<span class="Apple-converted-space">&nbsp;</span><i class="">either</i>&nbsp;allow reordering<span class="Apple-converted-space">&nbsp;</span><i class="">or</i>&nbsp;allow renaming, but not both</b>. Which do people think is more important?</div></div></blockquote><br class=""></div><div>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:</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>@fixedContents struct Foo {</div><div><div><span class="Apple-tab-span" style="white-space: pre;">                </span>@renamed(from: x, in: iOS 14)</div><div><span class="Apple-tab-span" style="white-space: pre;">                </span>var xCount: Int</div><div><span class="Apple-tab-span" style="white-space: pre;">                </span></div><div><span class="Apple-tab-span" style="white-space: pre;">                </span>@renamed(from: y,&nbsp;in: iOS 14)</div><div><span class="Apple-tab-span" style="white-space: pre;">                </span>var yAverage: Double</div><div><span class="Apple-tab-span" style="white-space: pre;">                </span></div><div><span class="Apple-tab-span" style="white-space: pre;">                </span>@renamed(from: z,&nbsp;in: iOS 14)</div><div><span class="Apple-tab-span" style="white-space: pre;">                </span>var zIdentifier: String</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>}</div><div><br class=""></div><div>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`.</div><div><br class=""></div><div>(In theory, we could do this with `@available`, but its current renaming support requires a dummy declaration.)</div><div><br class=""></div><div>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.</div><div class=""><br class=""></div></div><div class="">
<span class="Apple-style-span" style="border-collapse: separate; font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; line-height: normal; border-spacing: 0px;"><div class=""><div style="font-size: 12px; " class="">--&nbsp;</div><div style="font-size: 12px; " class="">Brent Royal-Gordon</div><div style="font-size: 12px; " class="">Architechies</div></div></span>

</div>
<br class=""></body></html>