[swift-dev] Preparing metadata records for ABI stability

[John McCall]

> On Nov 13, 2017, at 4:30 PM, Joe Groff <jgroff at apple.com> wrote:
> 
> On Nov 13, 2017, at 11:40 AM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
>> 
>> 
>>> On Nov 7, 2017, at 8:58 PM, Joe Groff via swift-dev <swift-dev at swift.org <mailto:swift-dev at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20171113/2b085452/attachment.html>