<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>Interesting, I didn't realize that worked. It does sound like a bug though; I would have expected the @available attribute to generate an NS_AVAILABLE() or NS_UNAVAILABLE() annotation on the Obj-C call.<br></div>
<div> </div>
<div>-Kevin Ballard</div>
<div> </div>
<div>On Mon, Jan 11, 2016, at 10:36 PM, Christopher Rogers wrote:<br></div>
<blockquote type="cite"><div>I've definitely wanted a feature like this. I hesitate to mention this because it might be a bug, but you can actually you can do this now. Just add<br></div>
<div> </div>
<div>@objc<br></div>
<div>@available(*, unavailable)<br></div>
<div> </div>
<div>and it won't be callable from Swift, while still getting bridged. (I'm not sure you need @objc but it serves as light documentation anyway.) The buggy part is the fact that it doesn't get bridged with the NS_UNAVAILABLE attribute. (It doesn't make much sense to have unavailable code in non-public APIs though so it may be correct behavior.) I use it a lot when porting code over to Swift to make sure people don't use the same old methods and classes they're used to using while providing a way to point them to the newer API by adding a message to the availability attribute.<br></div>
<div><div dir="ltr">On Tue, Jan 12, 2016 at 8:40 AM Andrew Bennett via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex;"><div dir="ltr"><div>+1 I've had similar issues, I've had to provide weaker Objective-C interface because my strong swift interfaces were incompatible with Objective-C.<br></div>
<div> </div>
<div>I've considered whether @objc(foo) implies public(objc) (in most cases), and if you'd need private(objc) if it did, but I think your proposal is more consistent/clear.<br></div>
<div> </div>
</div>
<div><div> </div>
<div><div>On Tue, Jan 12, 2016 at 9:51 AM, Kevin Ballard via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>></span> wrote:<br></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204, 204, 204);border-left-style:solid;padding-left:1ex;"><div>I could really use some feedback on this proposal. This is something that annoys me every time I write a pure-Swift API with an Obj-C wrapper (which, coincidentally, I'm doing again right at this moment). I'd really like to have some graceful way of handling this in Swift so the Obj-C compatibility API is not exposed to Swift clients, but this proposal can't move forward without community support.<br></div>
<div> <span><br>
-Kevin Ballard<br> <br>
On Tue, Dec 15, 2015, at 11:18 AM, Kevin Ballard wrote:<br></span></div>
<div><div><div>> 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.<br></div>
<div>
><br></div>
<div>
> 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.<br></div>
<div>
><br></div>
<div>
> 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.<br></div>
<div>
><br></div>
<div>
> Armed with this new modifier, I can start to write code like<br></div>
<div>
><br></div>
<div>
> class MyClass: NSObject {<br></div>
<div>
> func foo<T>(x: T) { ... }<br></div>
<div>
> }<br></div>
<div>
><br></div>
<div>
> extension MyClass {<br></div>
<div>
> @objc(foo) public(objc) private func __foo(x: AnyObject) { ... }<br></div>
<div>
> }<br></div>
<div>
><br></div>
<div>
> 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).<br></div>
<div>
><br></div>
<div>
> Alternatives:<br></div>
<div>
><br></div>
<div>
> * Add a new attribute @export_objc that has the same behavior.<br></div>
<div>
><br></div>
<div>
> * 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.<br></div>
<div>
><br></div>
<div>
> 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".<br></div>
<div>
><br></div>
<div>
> -Kevin Ballard<br></div>
<div>
_______________________________________________<br></div>
<div>
swift-evolution mailing list<br></div>
<div> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br></div>
<div> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div>
</div>
</div>
</blockquote></div>
<div> </div>
</div>
<div><img style="min-height:1px !important;width:1px !important;border-top-width:0px !important;border-right-width:0px !important;border-bottom-width:0px !important;border-left-width:0px !important;margin-top:0px !important;margin-bottom:0px !important;margin-right:0px !important;margin-left:0px !important;padding-top:0px !important;padding-bottom:0px !important;padding-right:0px !important;padding-left:0px !important;" border="0" height="1" width="1" alt="" src="https://www.fastmailusercontent.com/proxy/2ee0e02203ee7476fccd34d75d386e97a3463df6f6531b61c1ee8f2f2fce6a6c/8647470737a3f2f25723030323431303e23647e23756e64676279646e2e65647f27766f2f60756e6f35707e6d3757373264597639525468497357645b4034497832555d22364432514e4772685b41425653364931354778505f6448635a40365d2236413b6e6749497747784673596a45423d4678726178735d223641365644393e44465f6d22364331363057594d2232476d403a78663549486945587a665d22324664603772513f633b4039376e63423258385a4753445b615466496660753d223641734552413748393a4f6b6d223642666a62705231424571474f6636615f4a464d2232493241384e6757666563643a605a45613f616b4e45644a476f6d22324978456f69783a694f44646e677d22364731785e677b60596f684a7762676a4d613673365f4c4d657f634c683d23344/open">
_______________________________________________<br></div>
<div>
swift-evolution mailing list<br></div>
<div> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br></div>
<div> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div>
</blockquote></div>
</blockquote><div> </div>
</body>
</html>