[swift-dev] Type metadata and identity

[Andrew Trick]

> On Feb 23, 2016, at 4:55 PM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> 
>> On Feb 23, 2016, at 16:54 , Andrew Trick <atrick at apple.com <mailto:atrick at apple.com>> wrote:
>> 
>> 
>>> On Feb 23, 2016, at 1:51 PM, Jordan Rose via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>> 
>>> Hi, all (but especially the perf team). ChrisW and I are working on importing Objective-C generics as Swift generics <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006790.html>, getting at least the bare minimum working. One interesting thing here is that Objective-C generics are type-erased, meaning that there isn't a different Class for, e.g. NSLayoutAnchor<NSLayoutXAxisAnchor *> and NSLayoutAnchor<NSLayoutYAxisAnchor *>. That means that the type metadata pointers for those two types will be identical.
>>> 
>>> Can anyone think of problems this will cause? Do we rely on different types having different metadata for anything other than downcasting? (See the proposal for a discussion of downcasting.)
>> 
>> The optimizer might try to materialize a pointer metatype pointer from an AST type and emit direct comparisons with the ‘isa’ pointer. I don’t see why that would be a problem though, since the types are runtime equivalent anyway.
> 
> Right. I can imagine missed opportunities for CSE or even devirtualization, but would not expect miscompiles or changes in formally observable behavior between -O and -Onone

If we do materialize the metatype, I think we could actually optimize NSLayoutAnchor<NSLayoutXAxisAnchor *> as if it were NSLayoutAnchor<NSLayoutYAxisAnchor *>. I think would only matter if we had swift extensions of one type that didn’t extend the other, right? …

extension NSLayoutAnchor where T : ProtocolThatNSLayoutXAxisAnchorConformsTo {
  // some additional overrides
}

Is that sort of type extension possible? I think we’re saved by this: 
error: members of constrained extensions cannot be declared @objc

If this does turn out to be an issue, then maybe we can change the type system’s API so that the optimizer can’t ask for a metatype for an imported generic.

Andy 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20160223/3a32c873/attachment.html>