or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
+1. We may need to have a native implementation of the ‘dynamic’ keyword sometime in the future, and we’re locked out of doing that if we don’t get rid of the implied @objc now.
Charles
···
On Mar 31, 2017, at 10:29 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
Hello Swift community,
The second review of "SE-0160: Limiting @objc inference" begins now and runs through April 2, 2017. The proposal is available here:
or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
or, if you would like to keep your feedback private, directly to the
review manager.
*What goes into a review?*
The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:
* What is your evaluation of the proposal?
I do think this current iteration is an improvement. I have to say, though,
that I prefer Doug Gregor's spelling of `@implicitobjc` over
`@objcMembers`. It think the former explains the feature a little better
and also happens to be subjectively nicer-looking.
* Is the problem being addressed significant enough to warrant a change to
Swift?
Yes.
* Does this proposal fit well with the feel and direction of Swift?
Yes.
* If you have you used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?
N/A
* How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?
Quick reading of current revision; studied the previous iterations more
carefully and followed the discussion.
···
On Fri, Mar 31, 2017 at 10:29 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:
I feel the rules would be simpler if we either expected members to be objc or non-objc based on the parent type, not just overrides of the parent methods. I understand the space/performance optimization behind non-objc methods, but @objcMember and migration issues with key paths both would go away if @objc was just the default for members on an @objc class or Objective-C subclass.
Inference that a member is not @objc solely by its signature should go away. If the context expects @objc members, an incorrect signature should be an error.
* Is the problem being addressed significant enough to warrant a change to Swift?
Yes
* Does this proposal fit well with the feel and direction of Swift?
I think so, other than the complexity issues
* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I know of no other language with dispatch rules as complex as swift other than perhaps Objective-C++, which I haven’t used. I suspect in this small way the dispatch rules of Objective-C++ are simpler, because only message-dispatched members are allowed on the Objective-C classes and protocols (the C++ and Objective-C class systems are distinct)
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More than a quick reading, although I’ll admit I do not 100% understand the existing Swift rules of @objc and the effects of (for instance) declaring an @objc member on a non-@objc class.
or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
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.
* Is the problem being addressed significant enough to warrant a change to
Swift?
Yes.
* Does this proposal fit well with the feel and direction of Swift?
Yes, I think.
* How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?
In-depth study of the previous version and this new one too.
···
On Fri, Mar 31, 2017 at 5:29 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:
I think @objcMembers is more precise: it doesn’t imply that the class itself is @objc, just that the members are @objc.
- Doug
···
On Mar 31, 2017, at 9:35 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:
On Fri, Mar 31, 2017 at 10:29 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hello Swift community,
The second review of "SE-0160: Limiting @objc inference" begins now and runs through April 2, 2017. The proposal is available here:
or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
I do think this current iteration is an improvement. I have to say, though, that I prefer Doug Gregor's spelling of `@implicitobjc` over `@objcMembers`. It think the former explains the feature a little better and also happens to be subjectively nicer-looking.
I feel the rules would be simpler if we either expected members to be objc or non-objc based on the parent type, not just overrides of the parent methods. I understand the space/performance optimization behind non-objc methods, but @objcMember and migration issues with key paths both would go away if @objc was just the default for members on an @objc class or Objective-C subclass.
That’s (almost) the model we have today, except…
Inference that a member is not @objc solely by its signature should go away. If the context expects @objc members, an incorrect signature should be an error.
The effect of this is that a Swift class that derives NSObject would have to put “@nonobjc” on every method/property/etc. that uses Swift features that cannot be expressed in Objective-C. I don’t think that’s something we want.
- Doug
···
On Mar 31, 2017, at 11:32 AM, David Waite via swift-evolution <swift-evolution@swift.org> wrote:
You're right, I had to re-read the proposal a few times to grasp fully the
intention there.
There was some discussion in the previous thread that this would be needed
to infer @objc for implementations of @objc protocol requirements, but I
see that this is inferred without any such annotation in this version of
the proposal, which IMO is definitely reasonable.
It seems @objcMembers is really geared towards introspection. That finally
clicked just now. Would you consider, for those of us like me who are a
little slower on the uptake, making this even more explicit in the
spelling? I'm thinking along the lines of `@introspection(objc)`, which
nicely leaves open the possibility of future introspection facilities that
don't require Objective-C. I get that "members" is meant to decribe what's
going on that's different from plain @objc, but for me it took a while to
grasp the answer to the question, "Why is this another annotation, or in
other words, when would I use this instead?"
···
On Fri, Mar 31, 2017 at 13:30 Douglas Gregor <dgregor@apple.com> wrote:
On Mar 31, 2017, at 9:35 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:
On Fri, Mar 31, 2017 at 10:29 AM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:
Hello Swift community,
The second review of "SE-0160: Limiting @objc inference" begins now and
runs through April 2, 2017. The proposal is available here:
or, if you would like to keep your feedback private, directly to the
review manager.
*What goes into a review?*
The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:
* What is your evaluation of the proposal?
I do think this current iteration is an improvement. I have to say,
though, that I prefer Doug Gregor's spelling of `@implicitobjc` over
`@objcMembers`. It think the former explains the feature a little better
and also happens to be subjectively nicer-looking.
I think @objcMembers is more precise: it doesn’t imply that the class
itself is @objc, just that the members are @objc.
@objc on extensions behaves this way; the compiler will produce an error if the entity cannot be exposed to Objective-C.
- Doug
···
On Apr 4, 2017, at 12:31 PM, Víctor Pimentel Rodríguez via swift-evolution <swift-evolution@swift.org> wrote:
Sorry to be late :/
On Fri, Mar 31, 2017 at 5:29 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@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.
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!
···
Enviado desde mi iPhone
El 4 abr 2017, a las 22:04, Douglas Gregor <dgregor@apple.com> escribió:
On Apr 4, 2017, at 12:31 PM, Víctor Pimentel Rodríguez via swift-evolution <swift-evolution@swift.org> wrote:
On Fri, Mar 31, 2017 at 5:29 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
You're right, I had to re-read the proposal a few times to grasp fully the intention there.
There was some discussion in the previous thread that this would be needed to infer @objc for implementations of @objc protocol requirements, but I see that this is inferred without any such annotation in this version of the proposal, which IMO is definitely reasonable.
Right. We’ll infer @objc when the declaration implements a requirement of an @objc protocol.
It seems @objcMembers is really geared towards introspection. That finally clicked just now. Would you consider, for those of us like me who are a little slower on the uptake, making this even more explicit in the spelling? I'm thinking along the lines of `@introspection(objc)`, which nicely leaves open the possibility of future introspection facilities that don't require Objective-C. I get that "members" is meant to decribe what's going on that's different from plain @objc, but for me it took a while to grasp the answer to the question, "Why is this another annotation, or in other words, when would I use this instead?”
Introspection is a legitimate use case, but it’s not the only use case for @objcMembers, and it doesn’t really convey what the attribute does—it makes the members @objc.
- Doug
···
On Apr 1, 2017, at 2:52 AM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:
On Fri, Mar 31, 2017 at 13:30 Douglas Gregor <dgregor@apple.com <mailto:dgregor@apple.com>> wrote:
On Mar 31, 2017, at 9:35 AM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Fri, Mar 31, 2017 at 10:29 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hello Swift community,
The second review of "SE-0160: Limiting @objc inference" begins now and runs through April 2, 2017. The proposal is available here:
or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
I do think this current iteration is an improvement. I have to say, though, that I prefer Doug Gregor's spelling of `@implicitobjc` over `@objcMembers`. It think the former explains the feature a little better and also happens to be subjectively nicer-looking.
I think @objcMembers is more precise: it doesn’t imply that the class itself is @objc, just that the members are @objc.
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?
Yes.
And would extensions of such classes allow those members?
Yes. Also true for subclasses and their extensions.
Do I need to put @objc in every extension of a @objcMembers class to get that compiler error?
Yes.
By the way, I very much appreciate the level of care that you put into this proposal and its implementation. Thank you very much!
I'm looking forward to getting feedback on how it works out in practice. I've had pretty good luck with my our migrations.
- Doug
···
Sent from my iPhone
On Apr 5, 2017, at 1:19 AM, Víctor Pimentel <vpimentel@tuenti.com> wrote:
El 4 abr 2017, a las 22:04, Douglas Gregor <dgregor@apple.com> escribió:
On Apr 4, 2017, at 12:31 PM, Víctor Pimentel Rodríguez via swift-evolution <swift-evolution@swift.org> wrote:
On Fri, Mar 31, 2017 at 5:29 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote: