To avoid beating a dead horse, I’ll sum up my sentiments by saying that it
seems clear Selectors as they currently exist are a fairly outdated and
confusing approach for Objective-C and even more so for Swift.
When learning or developing a new paradigm, it’s very easy to bring the
baggage of the old philosophy into the new approach. While adding the
ability to initialize Selectors with a function/closure is certainly an
improvement, (and possibly should be implemented regardless), it also seems
to be a very non-Swift solution to the problems Selectors are trying to
If Classes like UIGestureRecognizers were being written today without
Selectors already in existence, I find it hard to believe they would be
created when a function reference or closure/block would be more
understandable and reliable in most cases.
With that in mind, the more forward thinking and swift-like approach
appears to be rewriting or replacing the APIs that use selectors to use
newer strategies to accomplish the same thing. There may be edge cases
where the dynamism and flexibility of Selectors are needed or desired, but
this is by no means the norm and should only be considered on a case by
- *What is your evaluation of the proposal?*
- Possibly necessary, but it seems to be a workaround, not a solution
- * Is the problem being addressed significant enough to warrant a
change to Swift?*
- Yes. Whether with this solution or another, it is a serious
oversight of the current platform
- *Does this proposal fit well with the feel and direction of Swift?*
- Direction, yes. Feel, no.
- *If you have you used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?*
- I haven’t used another language that uses a Selector-like approach.
Yet another reason why it should be changed
- How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
- Roughly 7 out of 10.