[swift-evolution] [Review #2] SE-0160: Limiting @objc inference

Douglas Gregor dgregor at apple.com
Tue Apr 4 15:04:25 CDT 2017


> On Apr 4, 2017, at 12:31 PM, Víctor Pimentel Rodríguez via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Sorry to be late :/
> 
> On Fri, Mar 31, 2017 at 5:29 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> * What is your evaluation of the proposal?
> 
> More positive than the first one, but still some rough edges.
> 
> One concern that I still have is that if we use @objcMembers, @nonobjc methods/properties are going to be even trickier to find.
> 
> If such modifier existed, I would like the compiler to warn me of public methods/properties that cannot be bridged to ObjC, because I have explicitly told the compiler that I want this object to live in the ObjC runtime. Of course, with a fixit recommending something like explicitly using @nonobjc.

@objc on extensions behaves this way; the compiler will produce an error if the entity cannot be exposed to Objective-C.

	- Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170404/d312edb5/attachment.html>


More information about the swift-evolution mailing list