Any possibility of selectively disabling resilient types for certain modules?

I develop an app along with a framework that it bundles. Because it's bundling the framework, there's no need for ABI stability in the framework, as there's no way to load a version of the framework other than the one it's compiled against.

Unfortunately, the new opaque result type feature of Swift 5.1 seems to force the use of resilient types and requires runtime support, meaning it can't be deployed earlier than iOS 13 / macOS 10.15.

Weirdly enough, in a quick test this is actually true within the same module. I assume that's a bug (SR-10925) as there's no reason at all to require resilient types within a module.

In any case, even assuming that worked, I'm very interested in being able to add APIs to my private framework that use opaque result types, but the only way to do that is to have some mechanism of saying "disable ABI stability behavior for this module". I'm not aware of any way to do this now. Has this been discussed before?

Opaque types are orthogonal to resilience. Opaque types are separately compiled, and it takes an optimization pass to replace them with underlying concrete types where possible. Even within a module, you'd need whole-module optimization to propagate that underlying type information across compilation units.

Why does this necessitate calling into the standard library though? Why can't the code that declares the opaque result type have a companion symbol which contains the opaque type metadata?

There is a companion symbol with the opaque type metadata, and the runtime call interprets that.

Ok, but the point is, why does this need to round-trip through the standard library at all? The info is coming from within my module. The consumer is within my module too. There seems to be no actual need for an OS requirement in this situation.

You're absolutely right that opaque types could in theory be completely substituted out within a module. It's tricky across files without WMO since it would mean that you still need to type check opaque types in other files to get that information. We haven't implemented this yet.

1 Like

In the fullness of time, I hope we do get the opportunity to implement the necessary backward deployment hooks for the Swift 5.0 runtime so we can lift the runtime restriction too.

2 Likes