@@ -699,7 +699,7 @@ you replace a native Objective-C `@implementation Foo (Bar)` with a Swift
699
699
700
700
You create a class with this feature very differently from normal ObjC interop:
701
701
702
- 1 . Hand-write headers that declare the classes' Objective-C interface, just as
702
+ 1 . Hand-write headers that declare the class's Objective-C interface, just as
703
703
you would for a native Objective-C class. Since you're handwriting these
704
704
headers, you can write them just as you would for an Objective-C class:
705
705
splitting them across multiple files, grouping related declarations together,
@@ -721,28 +721,35 @@ You create a class with this feature very differently from normal ObjC interop:
721
721
* To implement a category in Swift, use
722
722
` @_objcImplementation(CategoryName) extension ClassName ` .
723
723
724
- * We should think about Objective-C generics.
725
-
726
- 4 . Every member of an ` @_objcImplementation ` extension should be either ` @objc `
727
- or ` final ` . The ` final ` members can be made ` public ` if you want to expose
728
- them to Swift clients. The ` @objc ` members are implicitly ` dynamic ` .
724
+ The members of an ` @_objcImplementation ` extension should fall into one of
725
+ three categories:
729
726
730
- * Eventually, we'd like to allow members which are not explicitly marked
731
- ` @objc ` . The compiler will check that they match something declared in the
732
- header, and if they do, it will automatically apply appropriate attributes.
733
- If not, it will reject them. Members with an explicit ` @objc ` will not be
734
- checked, so you can define helpers that are callable by selector but not in
735
- any header.
727
+ * ** Swift-only members** include any member marked ` final ` . These are not
728
+ ` @objc ` or ` dynamic ` and are only callable from Swift. Use these for
729
+ Swift-only APIs, random helper methods, etc.
730
+
731
+ * ** ObjC helper members** include any non-` final ` member marked ` fileprivate `
732
+ or ` private ` . These are implicitly ` @objc dynamic ` . Use these for action
733
+ methods, selector-based callbacks, and other situations where you need a
734
+ helper method to be accessible from an Objective-C message.
736
735
737
- * Eventually, we want the main ` @_objcImplementation ` extension to be able to
738
- declare stored properties that aren't in the interface. We also want
739
- ` final ` stored properties to be allowed to be resilent Swift types, but
740
- it's not clear how to achieve that without boxing them in ` __SwiftValue `
741
- (which we might do as a stopgap).
736
+ * ** Member implementations** include any other non-` final ` member. These are
737
+ implicitly ` @objc dynamic ` and must match a member declared in the
738
+ Objective-C header. Use these to implement the APIs declared in your
739
+ headers. Swift will emit an error if these don't match your headers.
740
+
741
+ Notes:
742
+
743
+ * We don't currently plan to support ObjC generics.
744
+
745
+ * Eventually, we want the main ` @_objcImplementation ` extension to be able to
746
+ declare stored properties that aren't in the interface. We also want
747
+ ` final ` stored properties to be allowed to be resilent Swift types, but
748
+ it's not clear how to achieve that without boxing them in ` __SwiftValue `
749
+ (which we might do as a stopgap).
742
750
743
- * We should think about ObjC ` direct ` members.
744
-
745
- * Access control design for ObjC methods TBD.
751
+ * We should think about ObjC "direct" members, but that would probably
752
+ require a way to spell this in Swift.
746
753
747
754
## ` @_objc_non_lazy_realization `
748
755
0 commit comments