On Nov 13, 2017, at 11:40 AM, John McCall <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.
> - 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.
- 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.)
- 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).
> - 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.
-Joe
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
