> On Nov 13, 2017, at 4:30 PM, Joe Groff <jgr...@apple.com> wrote: > > On Nov 13, 2017, at 11:40 AM, John McCall <rjmcc...@apple.com > <mailto:rjmcc...@apple.com>> wrote: >> >> >>> On Nov 7, 2017, at 8:58 PM, Joe Groff via swift-dev <swift-dev@swift.org >>> <mailto:swift-dev@swift.org>> wrote: >>> >>> 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. >>> >> >> Overall, I think this is a nice description of the problem. A few comments: >> >> - One notable omission here is that you don't discuss nominal type >> descriptors at all. > > 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.
Okay, great. I guess that's what you meant by "other data structures" above, sorry. >> - 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. > > Maybe not. I can think of a few possible evolution avenues to keep room for: > > - 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. 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. > - 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.) 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. > - 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). Yeah, Pavel and I have been working on that. >> - I think having a single "value type" metadata kind for enums / structs >> makes sense, assuming we can discriminate them via the NTD. > > Agreed. > >> - 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. > > 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. Agreed. John.
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
