> On Jan 26, 2017, at 12:45 AM, Andrew Trick <atr...@apple.com> wrote: > > >> On Jan 25, 2017, at 6:13 PM, Joe Groff <jgr...@apple.com> wrote: >> >>> Naturally, opaque types must limit some optimizations, such as inlining. >> >> I don't see how opaque types by themselves prevent inlining. You can inline >> a generic into another generic, or a function using a resilient type into >> another function. > > Good point. I was just hand-waving here about resilient types, which we can’t > inline by design, and archetypes where we can’t inline protocol methods > because method resolution requires specialization. But yeah, we should be > inlining methods on unbound generic nominal types. I updated the doc.
We can't inline any information about the type layout of a resilient type, but it wouldn't block inlining of functions that use values of the resilient type when we have visibility into their bodies. It doesn't seem right to me to call them out as "not inlinable" when most of the non-inlinable things about them, like layout, value witnesses, and type metadata, are below the abstraction level of SIL. -Joe _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
