<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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.</div><div class=""><div class=""><div class="">
<br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;" class="">Félix</span>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 5 janv. 2016 à 17:56:42, Kevin Ballard <<a href="mailto:kevin@sb.org" class="">kevin@sb.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class="">
<title class=""></title>
<div class=""><div class="">Code completion aside, it just makes me really unhappy to expose a Swift API that nobody should <i class="">ever</i> 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.<br class=""></div>
<div class=""> </div>
<div class="">-Kevin Ballard</div>
<div class=""> </div>
<div class="">On Tue, Jan 5, 2016, at 02:55 PM, Félix Cloutier wrote:<br class=""></div>
<blockquote type="cite" class=""><div class="">.NET has an <a href="https://msdn.microsoft.com/en-us/library/system.componentmodel.editorbrowsableattribute(v=vs.110).aspx" class="">EditorBrowsable</a> attribute that controls whether things appear in autocomplete or not. I think that this alternative deserves some consideration.<br class=""></div>
<div class=""> </div>
<div class=""><div class="">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.<br class=""></div>
<div class=""><div class=""><div class=""> </div>
<div class=""><span class="colour" style=""><span class="font" style="font-family:'Lucida Grande'"><span class="size" style="font-size:12px">Félix</span></span></span><br class=""></div>
</div>
<div class=""> </div>
<div class=""><blockquote type="cite" class=""><div class="">Le 5 janv. 2016 à 15:23:55, Kevin Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :<br class=""></div>
<div class=""> </div>
<div class=""><div class=""><div class="">Proposal PR submitted as <a href="https://github.com/apple/swift-evolution/pull/85" class="">https://github.com/apple/swift-evolution/pull/85</a><br class=""></div>
<div class=""> </div>
<div class="">-Kevin Ballard<br class=""></div>
<div class=""> </div>
<div class="">On Tue, Dec 15, 2015, at 11:18 AM, Kevin Ballard wrote:<br class=""></div>
<blockquote type="cite" class=""><div class="">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 class=""></div>
<div class=""> </div>
<div class="">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 class=""></div>
<div class=""> </div>
<div class="">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 class=""></div>
<div class=""> </div>
<div class="">Armed with this new modifier, I can start to write code like<br class=""></div>
<div class=""> </div>
<div class="">class MyClass: NSObject {<br class=""></div>
<div class=""> func foo<T>(x: T) { ... }<br class=""></div>
<div class="">}<br class=""></div>
<div class=""> </div>
<div class="">extension MyClass {<br class=""></div>
<div class=""> @objc(foo) public(objc) private func __foo(x: AnyObject) { ... }<br class=""></div>
<div class="">}<br class=""></div>
<div class=""> </div>
<div class="">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 class=""></div>
<div class=""> </div>
<div class="">Alternatives:<br class=""></div>
<div class=""> </div>
<div class="">* Add a new attribute @export_objc that has the same behavior.<br class=""></div>
<div class=""> </div>
<div class="">* 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 class=""></div>
<div class=""> </div>
<div class="">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 class=""></div>
<div class=""> </div>
<div class="">-Kevin Ballard<br class=""></div>
</blockquote><div class="">_______________________________________________<br class=""></div>
<div class="">swift-evolution mailing list<br class=""></div>
<div class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""></div>
<div class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div>
</div>
</div>
</blockquote></div>
</div>
</div>
</blockquote><div class=""> </div>
</div>
</div></blockquote></div><br class=""></div></div></body></html>