> On Nov 13, 2017, at 2:16 PM, John McCall <rjmcc...@apple.com> wrote: > >> >> On Nov 13, 2017, at 4:30 PM, Joe Groff <jgr...@apple.com >> <mailto: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.
Sure. Optional's special kind does however still act as a physical subtype of general enum metadata layout. -Joe
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
