[Review] SE-0022: Referencing the Objective-C selector of a method

Evolution Announcements
1

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

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

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

Thank you,

-Joe

Review Manager

2

+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 <jgroff@apple.com> 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

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

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

Thank you,

-Joe

Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

3

# 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

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

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

Thank you,

-Joe

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

4

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

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

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

Thank you,

-Joe

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

5

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 <swift-evolution@swift.org> 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

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

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

Thank you,

-Joe

Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Javier Soto

6

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 <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 <mailto: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

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

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

Thank you,

-Joe

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

7

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 <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 <mailto: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

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

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

Thank you,

-Joe

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

8

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 <david@hartbit.com> wrote:

On 19 Jan 2016, at 23:43, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto: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 <mailto: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

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

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

Thank you,

-Joe

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

9

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 <david@hartbit.com> 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

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

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

Thank you,

-Joe

Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

10

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 <jtbandes@gmail.com> 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:))

?

11

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 <david@hartbit.com> wrote:

David.

On 19 Jan 2016, at 23:43, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto: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 <mailto: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

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

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

Thank you,

-Joe

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

12

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 <david@hartbit.com> 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

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

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

Thank you,

-Joe

Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

13

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 <jtbandes@gmail.com> wrote:

Jacob

On Tue, Jan 19, 2016 at 4:21 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jan 19, 2016, at 2:46 PM, David Hart <david@hartbit.com <mailto:david@hartbit.com>> 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 <mailto: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 <mailto: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

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

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

Thank you,

-Joe

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

14

Is there a well-defined meaning for `#` ? What about selector(x)?

···

On Tue, Jan 19, 2016 at 4:36 PM, Douglas Gregor <dgregor@apple.com> wrote:

On Jan 19, 2016, at 4:33 PM, Jacob Bandes-Storch <jtbandes@gmail.com> > 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 <david@hartbit.com> 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

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

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

Thank you,

-Joe

Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

15

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 <jtbandes@gmail.com> wrote:

On Tue, Jan 19, 2016 at 4:36 PM, Douglas Gregor <dgregor@apple.com <mailto:dgregor@apple.com>> wrote:

On Jan 19, 2016, at 4:33 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> 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 <mailto:swift-evolution@swift.org>> wrote:

On Jan 19, 2016, at 2:46 PM, David Hart <david@hartbit.com <mailto:david@hartbit.com>> 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 <mailto: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 <mailto: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

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

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

Thank you,

-Joe

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

16

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 <swift-evolution@swift.org> a écrit :

On Jan 19, 2016, at 2:56 PM, Jacob Bandes-Storch <jtbandes@gmail.com> 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

17

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 <swift-evolution@swift.org> wrote:

On Jan 19, 2016, at 4:40 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:

  - Doug

On Tue, Jan 19, 2016 at 4:36 PM, Douglas Gregor <dgregor@apple.com <mailto:dgregor@apple.com>> wrote:

On Jan 19, 2016, at 4:33 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> 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 <mailto:swift-evolution@swift.org>> wrote:

On Jan 19, 2016, at 2:46 PM, David Hart <david@hartbit.com <mailto:david@hartbit.com>> 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 <mailto: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 <mailto: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

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

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

Thank you,

-Joe

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

18

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 <swift-evolution@swift.org> wrote:

On Jan 19, 2016, at 4:52 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jan 19, 2016, at 4:40 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> 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”?

19

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 <swift-evolution@swift.org> wrote:

On Jan 19, 2016, at 4:52 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jan 19, 2016, at 4:40 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> 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 <dgregor@apple.com <mailto:dgregor@apple.com>> wrote:

On Jan 19, 2016, at 4:33 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> 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 <mailto:swift-evolution@swift.org>> wrote:

On Jan 19, 2016, at 2:46 PM, David Hart <david@hartbit.com <mailto:david@hartbit.com>> 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 <mailto: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 <mailto: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

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

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

Thank you,

-Joe

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

20

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 <clattner@apple.com> wrote:

On Jan 20, 2016, at 3:48 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jan 19, 2016, at 4:52 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Jan 19, 2016, at 4:40 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> 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.