[swift-dev] Preparing metadata records for ABI stability

[John McCall]

> On Nov 13, 2017, at 5:19 PM, Joe Groff <jgroff at apple.com> wrote:
> 
>> On Nov 13, 2017, at 2:16 PM, John McCall <rjmccall at apple.com <mailto:rjmccall at apple.com>> wrote:
>> 
>>> 
>>> On Nov 13, 2017, at 4:30 PM, Joe Groff <jgroff at apple.com <mailto: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.
> 
> Sure. Optional's special kind does however still act as a physical subtype of general enum metadata layout.

True.  We could change that, of course.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20171114/c7280ddd/attachment.html>