<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=""><br class=""><div><blockquote type="cite" class=""><div class="">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=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><p 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;" class="">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><br class=""></div>Okay, great. I guess that's what you meant by "other data structures" above, sorry.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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><br class=""></div><div>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><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class="">- The shape of existential type metadata could change quite a bit to support generalized existentials. (This isn't too much of an ABI problem yet, maybe, since there isn't really much type information to project from existential metadata in its current form.)</div></div></div></div></blockquote><div><br class=""></div>We should at least leave space for this, I agree. But again, if there are cases we can't express with the current format, we could certainly just create a new kind + format for them. We don't have compatibility requirements for types that aren't expressible in the current type system.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class="">- Functions have tended to grow lots of new top-level and per-argument bits. We'll want to ensure there's room for those (and it looks like Pavel's latest patch does).</div></div></div></div></blockquote><div><br class=""></div>Yeah, Pavel and I have been working on that.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""> - I think having a single "value type" metadata kind for enums / structs makes sense, assuming we can discriminate them via the NTD.</div></div></div></blockquote><div class=""><br class=""></div>Agreed.</div><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""> - I feel like we're not boxing ourselves in too much to assume a layout of the generic requirements. Having a base offset already imposes a pretty steep compatibility requirement — e.g. even if we significantly generalized a type's generic signature, we would still need to store old requirements (when actually obeyed) in the appropriate places for the old signature, or else the old pattern just doesn't work at all. As long as we can extend that with more information later, we don't really suffer from making layout assumptions today.</div></div></div></blockquote><br class=""></div><div class="">Sounds good. If, for some reason we needed to move the base offset of the generic argument structure to make room for new fields, we could conceivably ABI-version-gate the presence of those fields. Resilient types compiled with an older ABI would just have to either forgo those fields or fall into slower access paths to extract them.</div></div></div></blockquote><br class=""></div><div>Agreed.</div><div><br class=""></div><div>John.</div><br class=""></body></html>