> On Nov 13, 2017, at 5:19 PM, Joe Groff <jgr...@apple.com> wrote:
>
>> On Nov 13, 2017, at 2:16 PM, John McCall <rjmcc...@apple.com
>> <mailto: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.
True. We could change that, of course.
John.
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
