Require @usableFromInline on witnesses for non-type requirements too #20485
Conversation
|
@swift-ci Please test |
|
@swift-ci Please test source compatibility |
|
Build failed |
jrose-apple
force-pushed
the
witlesser
branch
from
916ee8f to
45cc9e1
Compare
|
@swift-ci Please test |
|
Build failed |
|
Build failed |
| @@ -118,7 +118,7 @@ internal class _EmptyDictionarySingleton: _RawDictionaryStorage { | |||
| } | |||
|
|
|||
| #if _runtime(_ObjC) | |||
| @objc | |||
| @objc @usableFromInline | |||
There was a problem hiding this comment.
Oh - these are correct but unfortunate: these are Objective-C entry points and they aren’t supposed to be visible (or used) as Swift methods.
We currently have _NSDictionaryCore and the other shadow protocols as public. I think we should make them internal and remove these usableFromInlines in a followup PR. Cc @airspeedswift, @Catfish-Man
There was a problem hiding this comment.
I tried but couldn't find an obvious way to do so. See the summary in the commit message for 1d437ca581e28601340bb63903bd5469af62646f.
| @@ -654,7 +654,7 @@ protocol _Unwrappable { | |||
| } | |||
|
|
|||
| extension Optional: _Unwrappable { | |||
| func unwrap() -> Any? { | |||
| @usableFromInline func unwrap() -> Any? { | |||
There was a problem hiding this comment.
TIL _Unwrappable is a thing. I think we should remove it.
|
(Waiting for Karoy to land his changes, then I'll rebase.) |
Follow-up to f33bf67 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 f33bf67, it'll be a warning in Swift 4 mode and an error in Swift 5 mode. rdar://problem/43824161
jrose-apple
force-pushed
the
witlesser
branch
from
45cc9e1 to
ac17b7c
Compare
|
@swift-ci Please test |
Follow-up to #20384 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:
There might be another solution to this in the future, but for now this is the simplest answer. Like #20384, it'll be a warning in Swift 4 mode and an error in Swift 5 mode.
rdar://problem/43824161