<div dir="ltr">+1 for that. Closures are much more swift-y than selectors (and honestly, even in Objective-C, selectors are a pain to use). This would definitely be nice, although I&#39;m not quite sure if it&#39;s possible with reasonable effort. Selectors are very, very different beasts.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 30, 2015 at 10:56 AM, James Campbell via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>What if selectors arguments could be imported into swift to take a closure instead ? </div><div><br></div><div>This would fit into the proposal to rewrite the imported objective c Apis </div><div><br></div><div>So </div><div><br></div><div>- addAction:(Selector)action</div><div><br></div><div>Becomes</div><div><br></div><div>addAction(action:(AnyObject)-&gt;Void)</div><div><br></div><div>Instead of</div><div><br></div><div>addAction(action:String) </div><div><br></div><div>Like it does now.</div><div><br>Sent from my iPhone</div><div><br><span class="">On 29 Dec 2015, at 21:46, Joe Groff via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br><br></span></div><div><div class="h5"><blockquote type="cite"><div><br><div><blockquote type="cite"><div>On Dec 29, 2015, at 12:19 PM, Douglas Gregor via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br><br>Sent from my iPhone</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br>On Dec 27, 2015, at 12:07 AM, Jacob Bandes-Storch &lt;<a href="mailto:jtbandes@gmail.com" target="_blank">jtbandes@gmail.com</a>&gt; wrote:<br><br></div><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div dir="ltr">This is a neat idea. Here are some of my thoughts after initial readthrough:<div><br></div><div>- For symmetry with Obj-C code, how about using &quot;@selector&quot;, such as @selector(UIView.`insertSubview(_:at:)`) ?</div></div></div></blockquote><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">@ means at-tribute in Swift, whereas this is a specific expression. </span><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br><blockquote type="cite"><div><div dir="ltr"><div>- Or, why bother with a new expression? Could the compiler just do this automatically when it encounters an @objc function being passed as a Selector? So, you&#39;d simply be able to say &quot;let sel1: Selector = UIView.`frame.get`&quot;</div></div></div></blockquote><div><br></div><div>It could, but I don&#39;t think it should: the operation is not common enough that making it implicit would reduce overall syntactic noise, and it would introduce ambiguities between selector- and closure-based APIs. </div></div></div></blockquote><div><br></div><div>Maybe we can make constructor-like &quot;Selector(Class.method)&quot; syntax work (and &quot;Selector(getterFor:/setterFor: Class.property)&quot; for property accessors) instead of introducing a new magic function name.</div><div><br></div><div>-Joe</div><br><blockquote type="cite"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite"><div><div dir="ltr"><div>- Should the migrator offer to convert string-constant selectors to this form?</div></div></div></blockquote><div><br></div>Yes, absolutely.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br><blockquote type="cite"><div><div dir="ltr"><div>- It might be worth considering this in the context of the &quot;type-safe selectors&quot; idea that was floating around a while back.</div></div></div></blockquote><div><br></div>Yes, I should have referenced that. Apologies!</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br><blockquote type="cite"><div><div dir="ltr"><div>- Would it be valid to qualify a function with a subclass&#39;s name, when it&#39;s really only defined on the superclass? That is, would &quot;objc_selector(MyView.`frame.get`)&quot; work even if MyView doesn&#39;t override the `frame` property?</div></div></div></blockquote><div><br></div>Yes. MyView still has that property even if it doesn&#39;t override it. <br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>I could see this last one as a potential source of user confusion, because naming a particular class wouldn&#39;t actually tell you which implementation gets called when performing the selector (that&#39;s just the nature of the Obj-C runtime).</div></div></div></blockquote><div><br></div>To some extent, that&#39;s the nature of overriding. But objective-c allows one to use a selector with an unrelated class, which can certainly be confusing. I feel like that comes from the runtime itself, and isn&#39;t something we can avoid with any syntax we pick. </div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div><div><div dir="ltr"><div>Jacob Bandes-Storch<br></div></div></div></div><br><div class="gmail_quote">On Sat, Dec 26, 2015 at 11:48 PM, Douglas Gregor via swift-evolution<span> </span><span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span><span> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi all,<br><br>Currently, producing an Objective-C selector in Swift is an error-prone operation. One effectively just writes a string literal and uses it in a context where an ObjectiveC.Selector is expected:<br><br>        control.sendAction(“doSomething:”, to: target, forEvent: event)<br><br>There are many points of failure here:<br><br>1) The compiler doesn’t syntax-check at all to make sure it’s a valid spelling for a selector<br>2) The compiler doesn’t look for existing methods with this selector anywhere<br>3) The mapping from a Swift method name to an Objective-C selector isn’t always immediately obvious (especially for initializers), and will be getting significantly more complicated with the renaming work for Swift 3 (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md</a>).<br><br>I suggest that we add an expression ‘objc_selector(method-reference)` that produces the Objective-C selector for the named method, and produces an error if the method does not have an Objective-C entry point. For example:<br><br>        control.sendAction(objc_selector(MyApplication.doSomething), to: target, forEvent: event)<br><br>“doSomething” is a method of MyApplication, which might even have a completely-unrelated name in Objective-C:<br><br>        extension MyApplication {<br>                @objc(jumpUpAndDown:)<br>                func doSomething(sender: AnyObject?) { … }<br>        }<br><br>By naming the Swift method and having objc_selector do the work to form the Objective-C selector, we free the programming from having to do the naming translation manually and get static checking that the method exists and is exposed to Objective-C.<br><br>This proposal composes with my “Generalized Naming for Any Function” proposal, which lets us name methods fully, including getters/setters:<br><br>        let sel1: Selector = objc_selector(UIView.`insertSubview(_:at:)`) // produces the Selector “insertSubview:atIndex:&quot;<br>        let sel2: Selector = objc_selector(UIView.`frame.get`) // produces the Selector “frame&quot;<br><br>I don’t like the `objc_selector` syntax at all, but otherwise I think this functionality is straightforward.<br><br>        - Doug<br><br>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></blockquote></div><br></div></div></div></blockquote></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=RoDF4MveSEMYBIqIJA6ub1g8cOZ-2BVYvqV-2FqygPhjPn-2B3KzVLW654-2FDboW3qTcE-2B-2B7WEpWSIbw3IKoHs2reV0x29-2Fdc3MyFuUnyOPgxiY4UkdiZmeJtbzupWFKi5vfh7JTw68hhweJefoQ6YmQusE6f-2BDZZQQT5ac3pWoHj8NAqsWNLR6Fk24faJz3q3QEsekUfycgCoUFzBSlVC1iix3ZluF-2FvfuZB3bBzSYAGR0Slk-3D" alt="" width="1" height="1" border="0" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;min-height:1px!important;width:1px!important;border-width:0px!important;margin:0px!important;padding:0px!important"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important"><span> </span></span><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">_______________________________________________</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">swift-evolution mailing list</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="mailto:swift-evolution@swift.org" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">swift-evolution@swift.org</a><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=xV0JY-2FdZMnUMvSFtZnLiBPRTDDOSQf3-2FpH33HYOlBxHSRDY1BPK0cXh38tjvK-2FQUobHY8QEFUSneE1h8hDGuiSSn2Fy13tVpTwwChGtpncz9A-2BrcyqIaaGWyzJlH1-2FrZP0vMfY8S1W0PI4dF-2BMgJlW5GZbDwzDThNc-2FP4SX36aM3KUjbQ7fGLzMa4XD9fvp-2BixtGu5JipGgc9FbGWRxdUYANVqVKodhZM7W27Y1xEcY-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">

</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=3X4jBaRMJYTgQaTXt-2FL0X83k5h3WwaDWbCmwjXS4P8ExOZX8ZpTVKajjRIO04wvC9wfGS1bJkPztlVQbuthFUvA0gR1tPGnrKNK7vV79Pfc7QcXL13nu4ElZipJj9tt7-2F2vgCnxcQhbNsYZqqAP-2FPRFEQIeG8QEJfAnqeL8L8u4BWSo0LHX158fTMWp5GAvbMLeMrV4fbvs9hYU1RXSrlczBXyII2DNOZmlTyGIXwYM-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
</div></div></div>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><font color="#000000" face="monospace" size="3">Author of the Sparkling language</font><div><font color="#000000" face="monospace" size="3"><a href="http://h2co3.org" target="_blank">http://h2co3.org/</a><br></font></div><div><font color="#000000" face="monospace" size="3"><br></font></div></div></div>
</div>