<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 13, 2017, at 2:16 PM, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div 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;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Nov 13, 2017, at 4:30 PM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">On Nov 13, 2017, at 11:40 AM, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:<br class=""><div class=""><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Nov 7, 2017, at 8:58 PM, Joe Groff via swift-dev <<a href="mailto:swift-dev@swift.org" class="">swift-dev@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><p class="" style="color: rgb(17, 17, 17); font-family: "Helvetica Neue", Helvetica, Arial, Verdana, sans-serif; word-wrap: break-word; margin: 1.3125em 0px; font-size: 1.1429em; line-height: 1.3125em;">I’m trying to plan out changes to our type metadata record formats for ABI stability. I’ll start by looking at the current situation and then make suggestions about things we ought to change. We want to settle on a design that leaves room for future expansion and runtime changes, and still allows efficient access to the most frequently-accessed parts of metadata. I’ll be looking exclusively at metadata records themselves for this message, leaving other data structures for separate scrutiny. I'd appreciate all your feedback.</p></div></div></blockquote><div class=""><br class=""></div></div><div class="">Overall, I think this is a nice description of the problem. A few comments:</div><div class=""><br class=""></div><div class=""> - One notable omission here is that you don't discuss nominal type descriptors at all.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Yeah, sorry if I didn't make that clear that that was intentional. I'm working on a plan for renovating nominal type descriptors in a separate document.</div></div></div></div></blockquote><div class=""><br class=""></div>Okay, great. I guess that's what you meant by "other data structures" above, sorry.</div><div 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;" class=""><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""> - For the structural types (tuples, functions, existentials, metatypes), I don't think there's any particular reason to abstract access to the component types. If there are future changes to these types that require additional data to be stored, I don't see any reason that that couldn't be stored compatibly with the current layout. We should make sure that all of these metadata have some space to encode flags and that reads of those flags are appropriately delimited, as opposed to e.g. assuming that an entire word is used to store a single enum.</div></div></div></blockquote><div class=""><br class=""></div><div class="">Maybe not. I can think of a few possible evolution avenues to keep room for:</div><div class=""><br class=""></div><div class="">- Some of these could conceivably become nominal types at some point. Tuple<T...> and Metatype<T> structs seem conceivable at some point in the future, and it might be nice if we can move the structural metadata formats over to nominal metadata at some point in the future. It may be sufficient to ensure that tuple metadata lays out its element type and field offset vectors in a way that's compatible with how a generic struct would.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Much like Optional has a special kind, I don't think it's unreasonable to say that special structural types could always have a special layout.</div></div></div></blockquote><div><br class=""></div>Sure. Optional's special kind does however still act as a physical subtype of general enum metadata layout.</div><div><br class=""></div><div>-Joe</div><div><br class=""></div></body></html>