# \[Review\] SE-0022: Referencing the Objective-C selector of a method **URL:** \ **Category:** Announcements\ **Created:** [January 18, 2016, 4:02pm UTC](https://forums.swift.org/t/review-se-0022-referencing-the-objective-c-selector-of-a-method/1118 "2016-01-18T16:02:27Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![Joe\_Groff](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joe_groff/32/1929_2.png) [@Joe\_Groff](https://forums.swift.org/u/Joe_Groff)\ **Post date:** [January 18, 2016, 4:02pm UTC](https://forums.swift.org/t/review-se-0022-referencing-the-objective-c-selector-of-a-method/1118/1 "2016-01-18T16:02:27Z")
Hello Swift community, The review of “Referencing the Objective-C selector of a method” begins now and runs through January 23, 2016. The proposal is available here:   [swift-evolution/0022-objc-selectors.md at master · apple/swift-evolution · GitHub](https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md) Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at   [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) 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 information about the Swift evolution process is available at   [swift-evolution/process.md at master · apple/swift-evolution · GitHub](https://github.com/apple/swift-evolution/blob/master/process.md) Thank you, -Joe Review Manager ---
**Author:** ![Nick\_Shelley](https://avatars.discourse-cdn.com/v4/letter/n/ba9def/32.png) [@Nick\_Shelley](https://forums.swift.org/u/Nick_Shelley)\ **Post date:** [January 18, 2016, 6:40pm UTC](https://forums.swift.org/t/review-se-0022-referencing-the-objective-c-selector-of-a-method/1118/2 "2016-01-18T18:40:26Z")
+1 Over the weekend I converted a `canPerformAction` method for UIMenuController actions from Objective-C to Swift and was sad that the compiler was helpful in Objective-C (with @selector syntax) but not in Swift. Anything that makes code less Stringly typed is a good thing in my opinion. I only did a quick reading of the proposal and didn't follow any discussion beforehand. > **···** > > On Mon, Jan 18, 2016 at 9:02 AM, Joe Groff \ wrote: > > > Hello Swift community, > > > > The review of “Referencing the Objective-C selector of a method” begins > > now and runs through January 23, 2016. The proposal is available here: > > > > [https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md](https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md) > > > > Reviews are an important part of the Swift evolution process. All reviews > > should be sent to the swift-evolution mailing list at > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > 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 information about the Swift evolution process is available at > > > > [https://github.com/apple/swift-evolution/blob/master/process.md](https://github.com/apple/swift-evolution/blob/master/process.md) > > > > Thank you, > > > > -Joe > > > > Review Manager > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution-announce mailing list > > swift-evolution-announce@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution-announce](https://lists.swift.org/mailman/listinfo/swift-evolution-announce) ---
**Author:** ![Felix\_Cloutier1](https://avatars.discourse-cdn.com/v4/letter/f/e47c2d/32.png) [@Felix\_Cloutier1](https://forums.swift.org/u/Felix_Cloutier1)\ **Post date:** [January 18, 2016, 6:21pm UTC](https://forums.swift.org/t/review-se-0022-referencing-the-objective-c-selector-of-a-method/1118/3 "2016-01-18T18:21:12Z")
# What is your evaluation of the proposal? I support it. # Is the problem being addressed significant enough to warrant a change to Swift? One great advantage of being able to name a selector from a method is that tools can tell that some method from some class is being used as a callback. It can't tell that just from a selector string. This will be useful for refactoring tools. I think that selectors are going to die a very slow death, so we might as well have decent support for them. # Does this proposal fit well with the feel and direction of Swift? I guess? # If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those? Selectors are pretty unique to Objective-C. # How much effort did you put into your review? A glance, a quick reading, or an in-depth study? I read the proposal and was already convinced. I followed a little bit of discussion and everything looked good. Félix > **···** > > > Le 18 janv. 2016 à 11:02:27, Joe Groff via swift-evolution \ a écrit : > > > > Hello Swift community, > > > > The review of “Referencing the Objective-C selector of a method” begins now and runs through January 23, 2016. The proposal is available here: > > > >   [https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md](https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md) > > > > Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at > > > >   [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > 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 information about the Swift evolution process is available at > > > >   [https://github.com/apple/swift-evolution/blob/master/process.md](https://github.com/apple/swift-evolution/blob/master/process.md) > > > > Thank you, > > > > -Joe > > > > Review Manager > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Joe\_Groff](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joe_groff/32/1929_2.png) [@Joe\_Groff](https://forums.swift.org/u/Joe_Groff)\ **Post date:** [January 19, 2016, 10:43pm UTC](https://forums.swift.org/t/review-se-0022-referencing-the-objective-c-selector-of-a-method/1118/4 "2016-01-19T22:43:36Z")
We discussed this proposal during our core team review meeting, and concerns were raised about the implementability of the proposed 'Selector(Type.method)' syntax. Producing the selector is something that can't quite be modeled as a real initializer, so the type checker would have to perform heroics to disambiguate a selector literal reference from a proper initializer call. We recommend reconsidering alternative syntactic forms for referencing the selector. Potential options include: - A unique prefix identifier, such as `objc_selector(Type.method)`, as you had originally proposed, or - Taking advantage of the fact that functions don't have members to ascribe special behavior to 'Type.method.objcSelector', or something like it. -Joe > **···** > > > On Jan 18, 2016, at 8:02 AM, Joe Groff via swift-evolution \ wrote: > > > > Hello Swift community, > > > > The review of “Referencing the Objective-C selector of a method” begins now and runs through January 23, 2016. The proposal is available here: > > > >   [https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md](https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md) > > > > Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at > > > >   [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > 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 information about the Swift evolution process is available at > > > >   [https://github.com/apple/swift-evolution/blob/master/process.md](https://github.com/apple/swift-evolution/blob/master/process.md) > > > > Thank you, > > > > -Joe > > > > Review Manager > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Javi](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/javi/32/404_2.png) [@Javi](https://forums.swift.org/u/Javi)\ **Post date:** [January 18, 2016, 6:35pm UTC](https://forums.swift.org/t/review-se-0022-referencing-the-objective-c-selector-of-a-method/1118/5 "2016-01-18T18:35:33Z")
What is your evaluation of the proposal? Strong +1. The syntax is clear and obvious, without looking at documentation, one could almost guess it, and that's always great. • Is the problem being addressed significant enough to warrant a change to Swift? Yup! Using objective-c APIs is still the bread and butter in Apple's platforms, where a lot of Swift code is written. Stringly-typed selectors are incredibly fragile. The target-selector pattern will still feel a bit foreign in Swift, but this will at least make it look like we're passing a partially-applied function. • Does this proposal fit well with the feel and direction of Swift? Yes, particularly with the proposed syntax to name any function. • How much effort did you put into your review? A glance, a quick reading, or an in-depth study? I followed the discussion on the topic prior to the proposal these past weeks, and read the proposal from begging to end. > **···** > > On Mon, Jan 18, 2016 at 10:21 AM Félix Cloutier \ wrote: > > > # What is your evaluation of the proposal? > > > > I support it. > > > > # Is the problem being addressed significant enough to warrant a change to > > Swift? > > > > One great advantage of being able to name a selector from a method is that > > tools can tell that some method from some class is being used as a > > callback. It can't tell that just from a selector string. This will be > > useful for refactoring tools. > > > > I think that selectors are going to die a very slow death, so we might as > > well have decent support for them. > > > > # Does this proposal fit well with the feel and direction of Swift? > > > > I guess? > > > > # If you have you used other languages or libraries with a similar > > feature, how do you feel that this proposal compares to those? > > > > Selectors are pretty unique to Objective-C. > > > > # How much effort did you put into your review? A glance, a quick reading, > > or an in-depth study? > > > > I read the proposal and was already convinced. I followed a little bit of > > discussion and everything looked good. > > > > Félix > > > > Le 18 janv. 2016 à 11:02:27, Joe Groff via swift-evolution \< \> swift-evolution@swift.org\> a écrit : > > > > Hello Swift community, > > > > The review of “Referencing the Objective-C selector of a method” begins > > now and runs through January 23, 2016. The proposal is available here: > > > > [https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md](https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md) > > > > Reviews are an important part of the Swift evolution process. All reviews > > should be sent to the swift-evolution mailing list at > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > 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 information about the Swift evolution process is available at > > > > [https://github.com/apple/swift-evolution/blob/master/process.md](https://github.com/apple/swift-evolution/blob/master/process.md) > > > > Thank you, > > > > -Joe > > > > Review Manager > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > -- > Javier Soto ---
**Author:** ![Erica\_Sadun](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/erica_sadun/32/243_2.png) [@Erica\_Sadun](https://forums.swift.org/u/Erica_Sadun)\ **Post date:** [January 20, 2016, 1:12am UTC](https://forums.swift.org/t/review-se-0022-referencing-the-objective-c-selector-of-a-method/1118/6 "2016-01-20T01:12:24Z")
The former seems more ObjCbridgish. The latter seems more Swiftish. While I prefer the aesthetics of the latter, the former seems to better call out the bridging semantics for anyone reading through code. I guess I'd want to know whether there are or will be similar approaches for example, I dunno, pulling Foundation objects in (like objc\_type(Dictionary)) and if so which approach would you use there? -- E, who is probably rambling but hopes this adds something to weighing between the two > **···** > > > On Jan 19, 2016, at 3:43 PM, Joe Groff via swift-evolution \ wrote: > > > > We discussed this proposal during our core team review meeting, and concerns were raised about the implementability of the proposed 'Selector(Type.method)' syntax. Producing the selector is something that can't quite be modeled as a real initializer, so the type checker would have to perform heroics to disambiguate a selector literal reference from a proper initializer call. We recommend reconsidering alternative syntactic forms for referencing the selector. Potential options include: > > > > - A unique prefix identifier, such as `objc_selector(Type.method)`, as you had originally proposed, or > > - Taking advantage of the fact that functions don't have members to ascribe special behavior to 'Type.method.objcSelector', or something like it. > > > > -Joe > > > > > On Jan 18, 2016, at 8:02 AM, Joe Groff via swift-evolution \\> wrote: > > > > > > Hello Swift community, > > > > > > The review of “Referencing the Objective-C selector of a method” begins now and runs through January 23, 2016. The proposal is available here: > > > > > >   [https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md](https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md) > > > > > > Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at > > > > > >   [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > 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 information about the Swift evolution process is available at > > > > > >   [https://github.com/apple/swift-evolution/blob/master/process.md](https://github.com/apple/swift-evolution/blob/master/process.md) > > > > > > Thank you, > > > > > > -Joe > > > > > > Review Manager > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org \ > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![hartbit](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/hartbit/32/738_2.png) [@hartbit](https://forums.swift.org/u/hartbit)\ **Post date:** [January 19, 2016, 10:46pm UTC](https://forums.swift.org/t/review-se-0022-referencing-the-objective-c-selector-of-a-method/1118/7 "2016-01-19T22:46:49Z")
What effect would that have? Would the options still return a type (Selector) that is CustomStringConvertible or would it just be compiler magic? David. > **···** > > > On 19 Jan 2016, at 23:43, Joe Groff via swift-evolution \ wrote: > > > > We discussed this proposal during our core team review meeting, and concerns were raised about the implementability of the proposed 'Selector(Type.method)' syntax. Producing the selector is something that can't quite be modeled as a real initializer, so the type checker would have to perform heroics to disambiguate a selector literal reference from a proper initializer call. We recommend reconsidering alternative syntactic forms for referencing the selector. Potential options include: > > > > - A unique prefix identifier, such as `objc_selector(Type.method)`, as you had originally proposed, or > > - Taking advantage of the fact that functions don't have members to ascribe special behavior to 'Type.method.objcSelector', or something like it. > > > > -Joe > > > > > On Jan 18, 2016, at 8:02 AM, Joe Groff via swift-evolution \\> wrote: > > > > > > Hello Swift community, > > > > > > The review of “Referencing the Objective-C selector of a method” begins now and runs through January 23, 2016. The proposal is available here: > > > > > >   [https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md](https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md) > > > > > > Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at > > > > > >   [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > 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 information about the Swift evolution process is available at > > > > > >   [https://github.com/apple/swift-evolution/blob/master/process.md](https://github.com/apple/swift-evolution/blob/master/process.md) > > > > > > Thank you, > > > > > > -Joe > > > > > > Review Manager > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org \ > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Joe\_Groff](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joe_groff/32/1929_2.png) [@Joe\_Groff](https://forums.swift.org/u/Joe_Groff)\ **Post date:** [January 19, 2016, 10:50pm UTC](https://forums.swift.org/t/review-se-0022-referencing-the-objective-c-selector-of-a-method/1118/8 "2016-01-19T22:50:14Z")
> What effect would that have? Would the options still return a type (Selector) that is CustomStringConvertible or would it just be compiler magic? > David. There's some compiler magic necessary no matter what, since it isn't otherwise possible to go from a function reference to a name within the language. Selector itself will remain printable AFAIK (however, the way it prints will become somewhat misleading to Swift code, as the Swift mapping of APIs diverges from ObjC). We'll likely want to phase out its StringLiteralConvertible-ness, though. -Joe > **···** > > > On Jan 19, 2016, at 2:46 PM, David Hart \ wrote: > > > > On 19 Jan 2016, at 23:43, Joe Groff via swift-evolution \\> wrote: > > > > > > We discussed this proposal during our core team review meeting, and concerns were raised about the implementability of the proposed 'Selector(Type.method)' syntax. Producing the selector is something that can't quite be modeled as a real initializer, so the type checker would have to perform heroics to disambiguate a selector literal reference from a proper initializer call. We recommend reconsidering alternative syntactic forms for referencing the selector. Potential options include: > > > > > > - A unique prefix identifier, such as `objc_selector(Type.method)`, as you had originally proposed, or > > > - Taking advantage of the fact that functions don't have members to ascribe special behavior to 'Type.method.objcSelector', or something like it. > > > > > > -Joe > > > > > > > On Jan 18, 2016, at 8:02 AM, Joe Groff via swift-evolution \\> wrote: > > > > > > > > Hello Swift community, > > > > > > > > The review of “Referencing the Objective-C selector of a method” begins now and runs through January 23, 2016. The proposal is available here: > > > > > > > >   [https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md](https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md) > > > > > > > > Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at > > > > > > > >   [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > 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 information about the Swift evolution process is available at > > > > > > > >   [https://github.com/apple/swift-evolution/blob/master/process.md](https://github.com/apple/swift-evolution/blob/master/process.md) > > > > > > > > Thank you, > > > > > > > > -Joe > > > > > > > > Review Manager > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > > > swift-evolution@swift.org \ > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org \ > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![jtbandes](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jtbandes/32/463_2.png) [@jtbandes](https://forums.swift.org/u/jtbandes)\ **Post date:** [January 19, 2016, 10:56pm UTC](https://forums.swift.org/t/review-se-0022-referencing-the-objective-c-selector-of-a-method/1118/9 "2016-01-19T22:56:30Z")
Is it any more feasible to allow     let sel: Selector = UIView.insertSubview(\_:belowSubview:) than it is to allow     let sel = Selector(UIView.insertSubview(\_:belowSubview:)) ? > **···** > > On Tue, Jan 19, 2016 at 2:50 PM, Joe Groff via swift-evolution \< swift-evolution@swift.org\> wrote: > > > On Jan 19, 2016, at 2:46 PM, David Hart \ wrote: > > > > What effect would that have? Would the options still return a type > > (Selector) that is CustomStringConvertible or would it just be compiler > > magic? > > David. > > > > There's some compiler magic necessary no matter what, since it isn't > > otherwise possible to go from a function reference to a name within the > > language. Selector itself will remain printable AFAIK (however, the way it > > prints will become somewhat misleading to Swift code, as the Swift mapping > > of APIs diverges from ObjC). We'll likely want to phase out its > > StringLiteralConvertible-ness, though. > > > > -Joe > > > > On 19 Jan 2016, at 23:43, Joe Groff via swift-evolution \< \> swift-evolution@swift.org\> wrote: > > > > We discussed this proposal during our core team review meeting, and > > concerns were raised about the implementability of the proposed > > 'Selector(Type.method)' syntax. Producing the selector is something that > > can't quite be modeled as a real initializer, so the type checker would > > have to perform heroics to disambiguate a selector literal reference from a > > proper initializer call. We recommend reconsidering alternative syntactic > > forms for referencing the selector. Potential options include: > > > > - A unique prefix identifier, such as `objc_selector(Type.method)`, as you > > had originally proposed, or > > - Taking advantage of the fact that functions don't have members to > > ascribe special behavior to 'Type.method.objcSelector', or something like > > it. > > > > -Joe > > > > On Jan 18, 2016, at 8:02 AM, Joe Groff via swift-evolution \< \> swift-evolution@swift.org\> wrote: > > > > Hello Swift community, > > > > The review of “Referencing the Objective-C selector of a method” begins > > now and runs through January 23, 2016. The proposal is available here: > > > > [https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md](https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md) > > > > Reviews are an important part of the Swift evolution process. All reviews > > should be sent to the swift-evolution mailing list at > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > 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 information about the Swift evolution process is available at > > > > [https://github.com/apple/swift-evolution/blob/master/process.md](https://github.com/apple/swift-evolution/blob/master/process.md) > > > > Thank you, > > > > -Joe > > > > Review Manager > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Joe\_Groff](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joe_groff/32/1929_2.png) [@Joe\_Groff](https://forums.swift.org/u/Joe_Groff)\ **Post date:** [January 19, 2016, 11:01pm UTC](https://forums.swift.org/t/review-se-0022-referencing-the-objective-c-selector-of-a-method/1118/10 "2016-01-19T23:01:11Z")
It is in fact somewhat easier; we do similar things for things like block and C function pointer conversions, where we allow an implicit conversion but then do a pass to see whether the thing we reference makes sense to reference as a function pointer. However, Doug balked at making this an implicit conversion, due to the ObjC-specificness and relative rarity of selectors. Implicit conversions tend to have hard-to-predict secondary costs. -Joe > **···** > > > On Jan 19, 2016, at 2:56 PM, Jacob Bandes-Storch \ wrote: > > > > Is it any more feasible to allow > > > >     let sel: Selector = UIView.insertSubview(\_:belowSubview:) > > > > than it is to allow > > > >     let sel = Selector(UIView.insertSubview(\_:belowSubview:)) > > > > ? ---
**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\ **Post date:** [January 20, 2016, 12:21am UTC](https://forums.swift.org/t/review-se-0022-referencing-the-objective-c-selector-of-a-method/1118/11 "2016-01-20T00:21:29Z")
> What effect would that have? Would the options still return a type (Selector) that is CustomStringConvertible or would it just be compiler magic? Either way, we’ll return a Selector. The concern about “Selector(x.foo)” is that we would need special, ad hoc overload-resolution rules to decide between this magic syntax and other initializers of Selector. Making it a separate expression (“objc\_selector(x.foo)”) or a special property on values of function type (“x.foo.selector”) eliminate that issue. We’d love to hear everyone’s thoughts on those approaches.   - Doug > **···** > > > On Jan 19, 2016, at 2:46 PM, David Hart \ wrote: > > > David. > > > > > On 19 Jan 2016, at 23:43, Joe Groff via swift-evolution \\> wrote: > > > > > > We discussed this proposal during our core team review meeting, and concerns were raised about the implementability of the proposed 'Selector(Type.method)' syntax. Producing the selector is something that can't quite be modeled as a real initializer, so the type checker would have to perform heroics to disambiguate a selector literal reference from a proper initializer call. We recommend reconsidering alternative syntactic forms for referencing the selector. Potential options include: > > > > > > - A unique prefix identifier, such as `objc_selector(Type.method)`, as you had originally proposed, or > > > - Taking advantage of the fact that functions don't have members to ascribe special behavior to 'Type.method.objcSelector', or something like it. > > > > > > -Joe > > > > > > > On Jan 18, 2016, at 8:02 AM, Joe Groff via swift-evolution \\> wrote: > > > > > > > > Hello Swift community, > > > > > > > > The review of “Referencing the Objective-C selector of a method” begins now and runs through January 23, 2016. The proposal is available here: > > > > > > > >   [https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md](https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md) > > > > > > > > Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at > > > > > > > >   [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > 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 information about the Swift evolution process is available at > > > > > > > >   [https://github.com/apple/swift-evolution/blob/master/process.md](https://github.com/apple/swift-evolution/blob/master/process.md) > > > > > > > > Thank you, > > > > > > > > -Joe > > > > > > > > Review Manager > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > > > swift-evolution@swift.org \ > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org \ > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![jtbandes](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jtbandes/32/463_2.png) [@jtbandes](https://forums.swift.org/u/jtbandes)\ **Post date:** [January 20, 2016, 12:33am UTC](https://forums.swift.org/t/review-se-0022-referencing-the-objective-c-selector-of-a-method/1118/12 "2016-01-20T00:33:16Z")
I'm fine with objc\_selector(x.foo) or @selector(x.foo). x.foo.selector is cute, but wouldn't this clash with property getters/setters? Jacob > **···** > > On Tue, Jan 19, 2016 at 4:21 PM, Douglas Gregor via swift-evolution \< swift-evolution@swift.org\> wrote: > > > On Jan 19, 2016, at 2:46 PM, David Hart \ wrote: > > > > What effect would that have? Would the options still return a type > > (Selector) that is CustomStringConvertible or would it just be compiler > > magic? > > > > Either way, we’ll return a Selector. The concern about “Selector(x.foo)” > > is that we would need special, ad hoc overload-resolution rules to decide > > between this magic syntax and other initializers of Selector. Making it a > > separate expression (“objc\_selector(x.foo)”) or a special property on > > values of function type (“x.foo.selector”) eliminate that issue. > > > > We’d love to hear everyone’s thoughts on those approaches. > > > > - Doug > > > > David. > > > > On 19 Jan 2016, at 23:43, Joe Groff via swift-evolution \< \> swift-evolution@swift.org\> wrote: > > > > We discussed this proposal during our core team review meeting, and > > concerns were raised about the implementability of the proposed > > 'Selector(Type.method)' syntax. Producing the selector is something that > > can't quite be modeled as a real initializer, so the type checker would > > have to perform heroics to disambiguate a selector literal reference from a > > proper initializer call. We recommend reconsidering alternative syntactic > > forms for referencing the selector. Potential options include: > > > > - A unique prefix identifier, such as `objc_selector(Type.method)`, as you > > had originally proposed, or > > - Taking advantage of the fact that functions don't have members to > > ascribe special behavior to 'Type.method.objcSelector', or something like > > it. > > > > -Joe > > > > On Jan 18, 2016, at 8:02 AM, Joe Groff via swift-evolution \< \> swift-evolution@swift.org\> wrote: > > > > Hello Swift community, > > > > The review of “Referencing the Objective-C selector of a method” begins > > now and runs through January 23, 2016. The proposal is available here: > > > > [https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md](https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md) > > > > Reviews are an important part of the Swift evolution process. All reviews > > should be sent to the swift-evolution mailing list at > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > 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 information about the Swift evolution process is available at > > > > [https://github.com/apple/swift-evolution/blob/master/process.md](https://github.com/apple/swift-evolution/blob/master/process.md) > > > > Thank you, > > > > -Joe > > > > Review Manager > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\ **Post date:** [January 20, 2016, 12:36am UTC](https://forums.swift.org/t/review-se-0022-referencing-the-objective-c-selector-of-a-method/1118/13 "2016-01-20T00:36:48Z")
> I'm fine with objc\_selector(x.foo) or > @selector(x.foo). @selector is a no-go: @ means “attribute” in Swift. > x.foo.selector is cute, but wouldn't this clash with property getters/setters? It would only be available on values of function type that refer to @objc methods or initializers. We would (still) need a different mechanism to get at the selectors of getters or setters; SE-0022 didn’t solve this problem either.   - Doug > **···** > > > On Jan 19, 2016, at 4:33 PM, Jacob Bandes-Storch \ wrote: > > > Jacob > > > > On Tue, Jan 19, 2016 at 4:21 PM, Douglas Gregor via swift-evolution \\> wrote: > > > > > On Jan 19, 2016, at 2:46 PM, David Hart \\> wrote: > > > > > > What effect would that have? Would the options still return a type (Selector) that is CustomStringConvertible or would it just be compiler magic? > > > > Either way, we’ll return a Selector. The concern about “Selector(x.foo)” is that we would need special, ad hoc overload-resolution rules to decide between this magic syntax and other initializers of Selector. Making it a separate expression (“objc\_selector(x.foo)”) or a special property on values of function type (“x.foo.selector”) eliminate that issue. > > > > We’d love to hear everyone’s thoughts on those approaches. > > > >   - Doug > > > > > David. > > > > > > > On 19 Jan 2016, at 23:43, Joe Groff via swift-evolution \\> wrote: > > > > > > > > We discussed this proposal during our core team review meeting, and concerns were raised about the implementability of the proposed 'Selector(Type.method)' syntax. Producing the selector is something that can't quite be modeled as a real initializer, so the type checker would have to perform heroics to disambiguate a selector literal reference from a proper initializer call. We recommend reconsidering alternative syntactic forms for referencing the selector. Potential options include: > > > > > > > > - A unique prefix identifier, such as `objc_selector(Type.method)`, as you had originally proposed, or > > > > - Taking advantage of the fact that functions don't have members to ascribe special behavior to 'Type.method.objcSelector', or something like it. > > > > > > > > -Joe > > > > > > > > > On Jan 18, 2016, at 8:02 AM, Joe Groff via swift-evolution \\> wrote: > > > > > > > > > > Hello Swift community, > > > > > > > > > > The review of “Referencing the Objective-C selector of a method” begins now and runs through January 23, 2016. The proposal is available here: > > > > > > > > > >   [https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md](https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md) > > > > > > > > > > Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at > > > > > > > > > >   [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > > > 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 information about the Swift evolution process is available at > > > > > > > > > >   [https://github.com/apple/swift-evolution/blob/master/process.md](https://github.com/apple/swift-evolution/blob/master/process.md) > > > > > > > > > > Thank you, > > > > > > > > > > -Joe > > > > > > > > > > Review Manager > > > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > swift-evolution mailing list > > > > > swift-evolution@swift.org \ > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > > > swift-evolution@swift.org \ > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org \ > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![jtbandes](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jtbandes/32/463_2.png) [@jtbandes](https://forums.swift.org/u/jtbandes)\ **Post date:** [January 20, 2016, 12:40am UTC](https://forums.swift.org/t/review-se-0022-referencing-the-objective-c-selector-of-a-method/1118/14 "2016-01-20T00:40:36Z")
Is there a well-defined meaning for `#` ? What about #selector(x)? > **···** > > On Tue, Jan 19, 2016 at 4:36 PM, Douglas Gregor \ wrote: > > > On Jan 19, 2016, at 4:33 PM, Jacob Bandes-Storch \ \> wrote: > > > > I'm fine with objc\_selector(x.foo) or > > > > @selector(x.foo). > > > > @selector is a no-go: @ means “attribute” in Swift. > > > > x.foo.selector is cute, but wouldn't this clash with property > > getters/setters? > > > > It would only be available on values of function type that refer to @objc > > methods or initializers. We would (still) need a different mechanism to get > > at the selectors of getters or setters; SE-0022 didn’t solve this problem > > either. > > > > - Doug > > > > Jacob > > > > On Tue, Jan 19, 2016 at 4:21 PM, Douglas Gregor via swift-evolution \< \> swift-evolution@swift.org\> wrote: > > > > > On Jan 19, 2016, at 2:46 PM, David Hart \ wrote: > > > > > > What effect would that have? Would the options still return a type > > > (Selector) that is CustomStringConvertible or would it just be compiler > > > magic? > > > > > > Either way, we’ll return a Selector. The concern about “Selector(x.foo)” > > > is that we would need special, ad hoc overload-resolution rules to decide > > > between this magic syntax and other initializers of Selector. Making it a > > > separate expression (“objc\_selector(x.foo)”) or a special property on > > > values of function type (“x.foo.selector”) eliminate that issue. > > > > > > We’d love to hear everyone’s thoughts on those approaches. > > > > > > - Doug > > > > > > David. > > > > > > On 19 Jan 2016, at 23:43, Joe Groff via swift-evolution \< \>\> swift-evolution@swift.org\> wrote: > > > > > > We discussed this proposal during our core team review meeting, and > > > concerns were raised about the implementability of the proposed > > > 'Selector(Type.method)' syntax. Producing the selector is something that > > > can't quite be modeled as a real initializer, so the type checker would > > > have to perform heroics to disambiguate a selector literal reference from a > > > proper initializer call. We recommend reconsidering alternative syntactic > > > forms for referencing the selector. Potential options include: > > > > > > - A unique prefix identifier, such as `objc_selector(Type.method)`, as > > > you had originally proposed, or > > > - Taking advantage of the fact that functions don't have members to > > > ascribe special behavior to 'Type.method.objcSelector', or something like > > > it. > > > > > > -Joe > > > > > > On Jan 18, 2016, at 8:02 AM, Joe Groff via swift-evolution \< \>\> swift-evolution@swift.org\> wrote: > > > > > > Hello Swift community, > > > > > > The review of “Referencing the Objective-C selector of a method” begins > > > now and runs through January 23, 2016. The proposal is available here: > > > > > > [https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md](https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md) > > > > > > Reviews are an important part of the Swift evolution process. All reviews > > > should be sent to the swift-evolution mailing list at > > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > 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 information about the Swift evolution process is available at > > > > > > [https://github.com/apple/swift-evolution/blob/master/process.md](https://github.com/apple/swift-evolution/blob/master/process.md) > > > > > > Thank you, > > > > > > -Joe > > > > > > Review Manager > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\ **Post date:** [January 20, 2016, 12:52am UTC](https://forums.swift.org/t/review-se-0022-referencing-the-objective-c-selector-of-a-method/1118/15 "2016-01-20T00:52:48Z")
> Is there a well-defined meaning for `#` ? Not yet. > What about #selector(x)? Objective-C selector formation is a \*very\* narrow feature to consider stealing one of our few underused sigils.   - Doug > **···** > > > On Jan 19, 2016, at 4:40 PM, Jacob Bandes-Storch \ wrote: > > > On Tue, Jan 19, 2016 at 4:36 PM, Douglas Gregor \\> wrote: > > > > > On Jan 19, 2016, at 4:33 PM, Jacob Bandes-Storch \\> wrote: > > > > > > I'm fine with objc\_selector(x.foo) or > > > > > @selector(x.foo). > > > > @selector is a no-go: @ means “attribute” in Swift. > > > > > x.foo.selector is cute, but wouldn't this clash with property getters/setters? > > > > It would only be available on values of function type that refer to @objc methods or initializers. We would (still) need a different mechanism to get at the selectors of getters or setters; SE-0022 didn’t solve this problem either. > > > >   - Doug > > > > > Jacob > > > > > > On Tue, Jan 19, 2016 at 4:21 PM, Douglas Gregor via swift-evolution \\> wrote: > > > > > > > On Jan 19, 2016, at 2:46 PM, David Hart \\> wrote: > > > > > > > > What effect would that have? Would the options still return a type (Selector) that is CustomStringConvertible or would it just be compiler magic? > > > > > > Either way, we’ll return a Selector. The concern about “Selector(x.foo)” is that we would need special, ad hoc overload-resolution rules to decide between this magic syntax and other initializers of Selector. Making it a separate expression (“objc\_selector(x.foo)”) or a special property on values of function type (“x.foo.selector”) eliminate that issue. > > > > > > We’d love to hear everyone’s thoughts on those approaches. > > > > > >   - Doug > > > > > > > David. > > > > > > > > > On 19 Jan 2016, at 23:43, Joe Groff via swift-evolution \\> wrote: > > > > > > > > > > We discussed this proposal during our core team review meeting, and concerns were raised about the implementability of the proposed 'Selector(Type.method)' syntax. Producing the selector is something that can't quite be modeled as a real initializer, so the type checker would have to perform heroics to disambiguate a selector literal reference from a proper initializer call. We recommend reconsidering alternative syntactic forms for referencing the selector. Potential options include: > > > > > > > > > > - A unique prefix identifier, such as `objc_selector(Type.method)`, as you had originally proposed, or > > > > > - Taking advantage of the fact that functions don't have members to ascribe special behavior to 'Type.method.objcSelector', or something like it. > > > > > > > > > > -Joe > > > > > > > > > > > On Jan 18, 2016, at 8:02 AM, Joe Groff via swift-evolution \\> wrote: > > > > > > > > > > > > Hello Swift community, > > > > > > > > > > > > The review of “Referencing the Objective-C selector of a method” begins now and runs through January 23, 2016. The proposal is available here: > > > > > > > > > > > >   [https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md](https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md) > > > > > > > > > > > > Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at > > > > > > > > > > > >   [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > > > > > 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 information about the Swift evolution process is available at > > > > > > > > > > > >   [https://github.com/apple/swift-evolution/blob/master/process.md](https://github.com/apple/swift-evolution/blob/master/process.md) > > > > > > > > > > > > Thank you, > > > > > > > > > > > > -Joe > > > > > > > > > > > > Review Manager > > > > > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > swift-evolution mailing list > > > > > > swift-evolution@swift.org \ > > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > swift-evolution mailing list > > > > > swift-evolution@swift.org \ > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org \ > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Felix\_Cloutier1](https://avatars.discourse-cdn.com/v4/letter/f/e47c2d/32.png) [@Felix\_Cloutier1](https://forums.swift.org/u/Felix_Cloutier1)\ **Post date:** [January 19, 2016, 11:47pm UTC](https://forums.swift.org/t/review-se-0022-referencing-the-objective-c-selector-of-a-method/1118/16 "2016-01-19T23:47:48Z")
What was the discussed design? It seems to me that if Swift has a CustomSelectorLiteralConvertible protocol that had a required init(selectorLiteral: String) method, it shouldn't be heroically difficult to disambiguate between a string and a method reference. Félix > **···** > > > Le 19 janv. 2016 à 18:01:11, Joe Groff via swift-evolution \ a écrit : > > > > > On Jan 19, 2016, at 2:56 PM, Jacob Bandes-Storch \ wrote: > > > > > > Is it any more feasible to allow > > > > > >    let sel: Selector = UIView.insertSubview(\_:belowSubview:) > > > > > > than it is to allow > > > > > >    let sel = Selector(UIView.insertSubview(\_:belowSubview:)) > > > > > > ? > > > > It is in fact somewhat easier; we do similar things for things like block and C function pointer conversions, where we allow an implicit conversion but then do a pass to see whether the thing we reference makes sense to reference as a function pointer. However, Doug balked at making this an implicit conversion, due to the ObjC-specificness and relative rarity of selectors. Implicit conversions tend to have hard-to-predict secondary costs. > > > > -Joe > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\ **Post date:** [January 20, 2016, 11:48pm UTC](https://forums.swift.org/t/review-se-0022-referencing-the-objective-c-selector-of-a-method/1118/17 "2016-01-20T23:48:11Z")
> > Is there a well-defined meaning for `#` ? > > Not yet. > > > What about #selector(x)? > > Objective-C selector formation is a \*very\* narrow feature to consider stealing one of our few underused sigils. Actually, this isn’t that much different from “#available”, in the sense that it’s a special, compiler-supported expression type for which we don’t want to necessarily steal a keyword. What do others think about “#selector”?   - Doug > **···** > > > On Jan 19, 2016, at 4:52 PM, Douglas Gregor via swift-evolution \ wrote: > > > > > On Jan 19, 2016, at 4:40 PM, Jacob Bandes-Storch \\> wrote: > > >   - Doug > > > > > On Tue, Jan 19, 2016 at 4:36 PM, Douglas Gregor \\> wrote: > > > > > > > On Jan 19, 2016, at 4:33 PM, Jacob Bandes-Storch \\> wrote: > > > > > > > > I'm fine with objc\_selector(x.foo) or > > > > > > > @selector(x.foo). > > > > > > @selector is a no-go: @ means “attribute” in Swift. > > > > > > > x.foo.selector is cute, but wouldn't this clash with property getters/setters? > > > > > > It would only be available on values of function type that refer to @objc methods or initializers. We would (still) need a different mechanism to get at the selectors of getters or setters; SE-0022 didn’t solve this problem either. > > > > > >   - Doug > > > > > > > Jacob > > > > > > > > On Tue, Jan 19, 2016 at 4:21 PM, Douglas Gregor via swift-evolution \\> wrote: > > > > > > > > > On Jan 19, 2016, at 2:46 PM, David Hart \\> wrote: > > > > > > > > > > What effect would that have? Would the options still return a type (Selector) that is CustomStringConvertible or would it just be compiler magic? > > > > > > > > Either way, we’ll return a Selector. The concern about “Selector(x.foo)” is that we would need special, ad hoc overload-resolution rules to decide between this magic syntax and other initializers of Selector. Making it a separate expression (“objc\_selector(x.foo)”) or a special property on values of function type (“x.foo.selector”) eliminate that issue. > > > > > > > > We’d love to hear everyone’s thoughts on those approaches. > > > > > > > >   - Doug > > > > > > > > > David. > > > > > > > > > > > On 19 Jan 2016, at 23:43, Joe Groff via swift-evolution \\> wrote: > > > > > > > > > > > > We discussed this proposal during our core team review meeting, and concerns were raised about the implementability of the proposed 'Selector(Type.method)' syntax. Producing the selector is something that can't quite be modeled as a real initializer, so the type checker would have to perform heroics to disambiguate a selector literal reference from a proper initializer call. We recommend reconsidering alternative syntactic forms for referencing the selector. Potential options include: > > > > > > > > > > > > - A unique prefix identifier, such as `objc_selector(Type.method)`, as you had originally proposed, or > > > > > > - Taking advantage of the fact that functions don't have members to ascribe special behavior to 'Type.method.objcSelector', or something like it. > > > > > > > > > > > > -Joe > > > > > > > > > > > > > On Jan 18, 2016, at 8:02 AM, Joe Groff via swift-evolution \\> wrote: > > > > > > > > > > > > > > Hello Swift community, > > > > > > > > > > > > > > The review of “Referencing the Objective-C selector of a method” begins now and runs through January 23, 2016. The proposal is available here: > > > > > > > > > > > > > >   [https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md](https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md) > > > > > > > > > > > > > > Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at > > > > > > > > > > > > > >   [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > > > > > > > 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 information about the Swift evolution process is available at > > > > > > > > > > > > > >   [https://github.com/apple/swift-evolution/blob/master/process.md](https://github.com/apple/swift-evolution/blob/master/process.md) > > > > > > > > > > > > > > Thank you, > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > Review Manager > > > > > > > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > > swift-evolution mailing list > > > > > > > swift-evolution@swift.org \ > > > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > swift-evolution mailing list > > > > > > swift-evolution@swift.org \ > > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > swift-evolution mailing list > > > > swift-evolution@swift.org \ > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Chris\_Lattner](https://avatars.discourse-cdn.com/v4/letter/c/bc8723/32.png) [@Chris\_Lattner](https://forums.swift.org/u/Chris_Lattner)\ **Post date:** [January 21, 2016, 3:39am UTC](https://forums.swift.org/t/review-se-0022-referencing-the-objective-c-selector-of-a-method/1118/18 "2016-01-21T03:39:47Z")
I think that #selector is workable and fits into the model - it would be simple to implement and not cause unnecessary complexity in the implementation. That said, I’m in favor of x.selector, or #selector(x). The former seems more syntactically elegant if it is practical. -Chris > **···** > > > On Jan 20, 2016, at 3:48 PM, Douglas Gregor via swift-evolution \ wrote: > > > > > On Jan 19, 2016, at 4:52 PM, Douglas Gregor via swift-evolution \\> wrote: > > > > > > > On Jan 19, 2016, at 4:40 PM, Jacob Bandes-Storch \\> wrote: > > > > > > > > Is there a well-defined meaning for `#` ? > > > > > > Not yet. > > > > > > > What about #selector(x)? > > > > > > Objective-C selector formation is a \*very\* narrow feature to consider stealing one of our few underused sigils. > > > > Actually, this isn’t that much different from “#available”, in the sense that it’s a special, compiler-supported expression type for which we don’t want to necessarily steal a keyword. What do others think about “#selector”? ---
**Author:** ![Erica\_Sadun](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/erica_sadun/32/243_2.png) [@Erica\_Sadun](https://forums.swift.org/u/Erica_Sadun)\ **Post date:** [January 21, 2016, 8:56pm UTC](https://forums.swift.org/t/review-se-0022-referencing-the-objective-c-selector-of-a-method/1118/19 "2016-01-21T20:56:06Z")
I like that it "matches" #available and establishes the # prefix as a (to paraphrase) special, compiler-supported expression type that doesn't steal a keyword. -- E > **···** > > > On Jan 20, 2016, at 4:48 PM, Douglas Gregor via swift-evolution \ wrote: > > > > > On Jan 19, 2016, at 4:52 PM, Douglas Gregor via swift-evolution \\> wrote: > > > > > > > On Jan 19, 2016, at 4:40 PM, Jacob Bandes-Storch \\> wrote: > > > > > > > > Is there a well-defined meaning for `#` ? > > > > > > Not yet. > > > > > > > What about #selector(x)? > > > > > > Objective-C selector formation is a \*very\* narrow feature to consider stealing one of our few underused sigils. > > > > Actually, this isn’t that much different from “#available”, in the sense that it’s a special, compiler-supported expression type for which we don’t want to necessarily steal a keyword. What do others think about “#selector”? > > > >   - Doug > > > > >   - Doug > > > > > > > On Tue, Jan 19, 2016 at 4:36 PM, Douglas Gregor \\> wrote: > > > > > > > > > On Jan 19, 2016, at 4:33 PM, Jacob Bandes-Storch \\> wrote: > > > > > > > > > > I'm fine with objc\_selector(x.foo) or > > > > > > > > > @selector(x.foo). > > > > > > > > @selector is a no-go: @ means “attribute” in Swift. > > > > > > > > > x.foo.selector is cute, but wouldn't this clash with property getters/setters? > > > > > > > > It would only be available on values of function type that refer to @objc methods or initializers. We would (still) need a different mechanism to get at the selectors of getters or setters; SE-0022 didn’t solve this problem either. > > > > > > > >   - Doug > > > > > > > > > Jacob > > > > > > > > > > On Tue, Jan 19, 2016 at 4:21 PM, Douglas Gregor via swift-evolution \\> wrote: > > > > > > > > > > > On Jan 19, 2016, at 2:46 PM, David Hart \\> wrote: > > > > > > > > > > > > What effect would that have? Would the options still return a type (Selector) that is CustomStringConvertible or would it just be compiler magic? > > > > > > > > > > Either way, we’ll return a Selector. The concern about “Selector(x.foo)” is that we would need special, ad hoc overload-resolution rules to decide between this magic syntax and other initializers of Selector. Making it a separate expression (“objc\_selector(x.foo)”) or a special property on values of function type (“x.foo.selector”) eliminate that issue. > > > > > > > > > > We’d love to hear everyone’s thoughts on those approaches. > > > > > > > > > >   - Doug > > > > > > > > > > > David. > > > > > > > > > > > > > On 19 Jan 2016, at 23:43, Joe Groff via swift-evolution \\> wrote: > > > > > > > > > > > > > > We discussed this proposal during our core team review meeting, and concerns were raised about the implementability of the proposed 'Selector(Type.method)' syntax. Producing the selector is something that can't quite be modeled as a real initializer, so the type checker would have to perform heroics to disambiguate a selector literal reference from a proper initializer call. We recommend reconsidering alternative syntactic forms for referencing the selector. Potential options include: > > > > > > > > > > > > > > - A unique prefix identifier, such as `objc_selector(Type.method)`, as you had originally proposed, or > > > > > > > - Taking advantage of the fact that functions don't have members to ascribe special behavior to 'Type.method.objcSelector', or something like it. > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > On Jan 18, 2016, at 8:02 AM, Joe Groff via swift-evolution \\> wrote: > > > > > > > > > > > > > > > > Hello Swift community, > > > > > > > > > > > > > > > > The review of “Referencing the Objective-C selector of a method” begins now and runs through January 23, 2016. The proposal is available here: > > > > > > > > > > > > > > > >   [https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md](https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md) > > > > > > > > > > > > > > > > Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at > > > > > > > > > > > > > > > >   [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > > > > > > > > > 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 information about the Swift evolution process is available at > > > > > > > > > > > > > > > >   [https://github.com/apple/swift-evolution/blob/master/process.md](https://github.com/apple/swift-evolution/blob/master/process.md) > > > > > > > > > > > > > > > > Thank you, > > > > > > > > > > > > > > > > -Joe > > > > > > > > > > > > > > > > Review Manager > > > > > > > > > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > > > swift-evolution mailing list > > > > > > > > swift-evolution@swift.org \ > > > > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > > > swift-evolution mailing list > > > > > > > swift-evolution@swift.org \ > > > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > > > swift-evolution mailing list > > > > > swift-evolution@swift.org \ > > > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > > swift-evolution mailing list > > > swift-evolution@swift.org \ > > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > swift-evolution mailing list > > swift-evolution@swift.org \ > > [https://lists.swift.org/mailman/listinfo/swift-evolution](https://lists.swift.org/mailman/listinfo/swift-evolution) ---
**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\ **Post date:** [January 21, 2016, 3:56am UTC](https://forums.swift.org/t/review-se-0022-referencing-the-objective-c-selector-of-a-method/1118/20 "2016-01-21T03:56:38Z")
The latter gives us easy extensions like   #selector(getter: MyType.property)   #selector(setter: MyType.property) #selector is sorta growing on me.   - Doug > **···** > > > On Jan 20, 2016, at 7:39 PM, Chris Lattner \ wrote: > > > > > On Jan 20, 2016, at 3:48 PM, Douglas Gregor via swift-evolution \\> wrote: > > > > > > > On Jan 19, 2016, at 4:52 PM, Douglas Gregor via swift-evolution \\> wrote: > > > > > > > > > On Jan 19, 2016, at 4:40 PM, Jacob Bandes-Storch \\> wrote: > > > > > > > > > > Is there a well-defined meaning for `#` ? > > > > > > > > Not yet. > > > > > > > > > What about #selector(x)? > > > > > > > > Objective-C selector formation is a \*very\* narrow feature to consider stealing one of our few underused sigils. > > > > > > Actually, this isn’t that much different from “#available”, in the sense that it’s a special, compiler-supported expression type for which we don’t want to necessarily steal a keyword. What do others think about “#selector”? > > > > I think that #selector is workable and fits into the model - it would be simple to implement and not cause unnecessary complexity in the implementation. > > > > That said, I’m in favor of x.selector, or #selector(x). The former seems more syntactically elegant if it is practical. [Next page](https://forums.swift.org/t/review-se-0022-referencing-the-objective-c-selector-of-a-method/1118.md?page=2)