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

[Víctor Pimentel]

Enviado desde mi iPhone
> El 4 abr 2017, a las 22:04, Douglas Gregor <dgregor at apple.com> escribió:
> 
> 
>> 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> 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

Yeah, I think you explained the behavior of extensions very well in the proposal:

> If some member within that extension cannot be exposed to Objective-C, such as SwiftClass.bar(), the compiler will produce an error.

My specific question was about implicitly @nonobjc members in a @objcMembers class. That is, would the compiler allow such member with no @nonobjc annotation? And would extensions of such classes allow those members? Do I need to put @objc in every extension of a @objcMembers class to get that compiler error?

By the way, I very much appreciate the level of care that you put into this proposal and its implementation. Thank you very much!

--
Víctor Pimentel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170405/30b61611/attachment.html>