@@ -621,7 +621,7 @@ you replace a native Objective-C `@implementation Foo (Bar)` with a Swift
621
621
622
622
You create a class with this feature very differently from normal ObjC interop:
623
623
624
- 1 . Hand-write headers that declare the classes' Objective-C interface, just as
624
+ 1 . Hand-write headers that declare the class's Objective-C interface, just as
625
625
you would for a native Objective-C class. Since you're handwriting these
626
626
headers, you can write them just as you would for an Objective-C class:
627
627
splitting them across multiple files, grouping related declarations together,
@@ -643,28 +643,35 @@ You create a class with this feature very differently from normal ObjC interop:
643
643
* To implement a category in Swift, use
644
644
` @_objcImplementation(CategoryName) extension ClassName ` .
645
645
646
- * We should think about Objective-C generics.
647
-
648
- 4 . Every member of an ` @_objcImplementation ` extension should be either ` @objc `
649
- or ` final ` . The ` final ` members can be made ` public ` if you want to expose
650
- them to Swift clients. The ` @objc ` members are implicitly ` dynamic ` .
646
+ The members of an ` @_objcImplementation ` extension should fall into one of
647
+ three categories:
651
648
652
- * Eventually, we'd like to allow members which are not explicitly marked
653
- ` @objc ` . The compiler will check that they match something declared in the
654
- header, and if they do, it will automatically apply appropriate attributes.
655
- If not, it will reject them. Members with an explicit ` @objc ` will not be
656
- checked, so you can define helpers that are callable by selector but not in
657
- any header.
649
+ * ** Swift-only members** include any member marked ` final ` . These are not
650
+ ` @objc ` or ` dynamic ` and are only callable from Swift. Use these for
651
+ Swift-only APIs, random helper methods, etc.
652
+
653
+ * ** ObjC helper members** include any non-` final ` member marked ` fileprivate `
654
+ or ` private ` . These are implicitly ` @objc dynamic ` . Use these for action
655
+ methods, selector-based callbacks, and other situations where you need a
656
+ helper method to be accessible from an Objective-C message.
658
657
659
- * Eventually, we want the main ` @_objcImplementation ` extension to be able to
660
- declare stored properties that aren't in the interface. We also want
661
- ` final ` stored properties to be allowed to be resilent Swift types, but
662
- it's not clear how to achieve that without boxing them in ` __SwiftValue `
663
- (which we might do as a stopgap).
658
+ * ** Member implementations** include any other non-` final ` member. These are
659
+ implicitly ` @objc dynamic ` and must match a member declared in the
660
+ Objective-C header. Use these to implement the APIs declared in your
661
+ headers. Swift will emit an error if these don't match your headers.
662
+
663
+ Notes:
664
+
665
+ * We don't currently plan to support ObjC generics.
666
+
667
+ * Eventually, we want the main ` @_objcImplementation ` extension to be able to
668
+ declare stored properties that aren't in the interface. We also want
669
+ ` final ` stored properties to be allowed to be resilent Swift types, but
670
+ it's not clear how to achieve that without boxing them in ` __SwiftValue `
671
+ (which we might do as a stopgap).
664
672
665
- * We should think about ObjC ` direct ` members.
666
-
667
- * Access control design for ObjC methods TBD.
673
+ * We should think about ObjC "direct" members, but that would probably
674
+ require a way to spell this in Swift.
668
675
669
676
## ` @_objc_non_lazy_realization `
670
677
0 commit comments