Why would you need to change the call sites? If you have existing Swift code that calls these Obj-C entrypoints, you simply wouldn't mark them as `public(objc)` but would just leave them as, well, public API.
There's nothing about this proposal that *forces* you to use it. You can continue to expose API to Obj-C the same way you do today. But the entire point of public(objc) is to expose API to Obj-C *without* exposing it to Swift as well (because there's already a better API exposed to Swift). -Kevin Ballard On Tue, Jan 5, 2016, at 03:15 PM, Félix Cloutier wrote: > I can't agree to that. If I gradually port an API from Objective-C to > Swift and at some point decide to go back to make a Swiftier entry > point, I'll be very disappointed that I need to change the call sites > to the Objective-C-compatible one, not because something will break, > but because the Swift mailing list thought Swift would be purer if I > couldn't use it. > > Félix > >> Le 5 janv. 2016 à 17:56:42, Kevin Ballard <[email protected]> a écrit : >> >> Code completion aside, it just makes me really unhappy to expose a >> Swift API that nobody should *ever* call from Swift. I just don't >> want to have that API be accessible at all when it only exists to >> serve as the Obj-C entrypoint. >> >> -Kevin Ballard >> >> On Tue, Jan 5, 2016, at 02:55 PM, Félix Cloutier wrote: >>> .NET has an EditorBrowsable[1] attribute that controls whether >>> things appear in autocomplete or not. I think that this alternative >>> deserves some consideration. >>> >>> It clearly won't have identical semantics, but I think that it would >>> be a little more graceful and much less involved. This solution only >>> needs a new attribute and SourceKit changes. >>> >>> Félix >>> >>>> Le 5 janv. 2016 à 15:23:55, Kevin Ballard via swift-evolution <swift- >>>> [email protected]> a écrit : >>>> >>>> Proposal PR submitted as >>>> https://github.com/apple/swift-evolution/pull/85 >>>> >>>> -Kevin Ballard >>>> >>>> On Tue, Dec 15, 2015, at 11:18 AM, Kevin Ballard wrote: >>>>> When writing ObjC code, there's a macro NS_REFINED_FOR_SWIFT (or >>>>> __attribute__((swift_private))) that mangles the name when >>>>> imported into Swift. The intention here is to hide an API from >>>>> normal Swift usage (but still make it callable) so that a better >>>>> Swift API can be written around it. >>>>> >>>>> But there's no facility for doing this in reverse. You can expose >>>>> Swift APIs to ObjC, but the API has to be ObjC-compatible. Which >>>>> means that if you have a non-ObjC-compatible API, you have to >>>>> write a separate API to expose it to ObjC, and this separate API >>>>> now shows up in the Swift API too. >>>>> >>>>> I think the simplest way to fix this is to allow for a modifier >>>>> public(objc) (following the syntax of private(set)). The only >>>>> thing this modifier does is ensure the declaration gets added to >>>>> the generated header as if it were public (or—for apps—internal). >>>>> If the declaration is not marked as @objc then it would emit an >>>>> error (it could imply @objc but it feels weird to me to have an >>>>> access control modifier do that). If the declaration is already >>>>> public (but not internal, so the same source can be used in apps >>>>> and libraries) it will emit a warning. >>>>> >>>>> Armed with this new modifier, I can start to write code like >>>>> >>>>> class MyClass: NSObject { func foo<T>(x: T) { ... } } >>>>> >>>>> extension MyClass { @objc(foo) public(objc) private func >>>>> __foo(x: AnyObject) { ... } } >>>>> >>>>> When used on a property that already has private(set), the >>>>> public(objc) modifier will only apply to the getter (e.g. the >>>>> private(set) takes precedence for the setter). >>>>> >>>>> Alternatives: >>>>> >>>>> * Add a new attribute @export_objc that has the same behavior. >>>>> >>>>> * Change the @objc attribute to take an optional second argument, >>>>> which may be the token "exported", as in @objc(foo,exported). >>>>> When using the "exported" token, the selector portion is >>>>> required. We could possibly support an empty selector to >>>>> indicate the default, as in @objc(,exported), but that looks >>>>> odd. >>>>> >>>>> My preference is for public(objc) as proposed as it matches more >>>>> closely with the intended behavior, which is "this API is private >>>>> in Swift and public in ObjC". >>>>> >>>>> -Kevin Ballard >>>> _______________________________________________ >>>> swift-evolution mailing list [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >> Links: 1. https://msdn.microsoft.com/en-us/library/system.componentmodel.editorbrowsableattribute(v=vs.110).aspx
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
