Follow-up to f33bf67dc9 for non-type requirements. We use non-type
witnesses for optimization purposes, so if we didn't enforce this we
might end up with something silently performing worse with parseable
interfaces than it would with swiftmodules. There's also a tricky case
where the client of the interface infers a different implementation:
public protocol Foo {
func foo()
}
extension Foo {
public func foo() { print("default") }
}
@usableFromInline struct FooImpl: Foo {
internal func foo() { print("actual") }
}
There might be another solution to this in the future, but for now
this is the simplest answer. Like f33bf67dc9, it'll be a warning in
Swift 4 mode and an error in Swift 5 mode.
rdar://problem/43824161
...when the protocol and the conforming type are not both public but
are both public-or-usableFromInline. It's possible to write inlinable
functions that depend on these types:
public protocol HasAssoc {
associatedtype Assoc
}
public func getAssoc<T: HasAssoc>(_: T) -> T.Assoc
@usableFromInline struct Impl: HasAssoc {
@usableFromInline typealias Assoc = Int
}
@inlinable func test() {
let x: Int = getAssoc(Impl())
}
rdar://problem/43824052
