[swift-evolution] [Proposal] Make optional protocol methods first class citizens

Austin Zheng austinzheng at gmail.com
Thu Mar 31 13:53:26 CDT 2016


This shouldn't be an issue in practice, though, since any UIKit control subclass has to inherit from NSObject anyways, which means they can always conform to any @objc protocol.

The main utility of removing the @objc requirement for optional protocol requirements would to allow their use in Swift code oriented away from Cocoa/Foundation, which is part of what Dave is objecting to.

Austin

> On Mar 31, 2016, at 11:49 AM, Yuval Tal via swift-evolution <swift-evolution at swift.org> wrote:
> 
> None taken. However, most of the delegate concept of UIKit relies heavily on this "nonsensical" requirement. It is impossible for someone to implement a control in swift which is "in the spirit" of UIKit, meaning the control has a delegate, with several methods that share the same name with different parameters, some are required and some are optional. I think it is not fair to tell users that they cannot implement something that is such a common and repeating pattern in the core. 
> 
> On Thu, Mar 31, 2016 at 2:23 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
> on Wed Mar 30 2016, Yuval Tal <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
> > Hi,
> >
> > I find that optional protocol methods to be very useful. However,
> > there is a caveat -- it needs to be mapped to @objc.  This puts a set
> > of limitations, such as: structures cannot be used as parameters as it
> > does not map to objective-c. What do you think about removing the
> > requirement of using @objc and allow to create optional methods
> > without these limitations?
> 
> Caveat: this is going to be strongly-worded; sorry in advance.  I think
> (no offense intended) it's a terrible idea.  The whole notion of an
> “optional requirement” is nonsensical to begin with, and the use of
> optional protocol requirements encourages a style of programming that
> lifts the responsibility of the protocol designer for careful design at
> the expense of clients of the protocol.  There are better ways to do
> things; let's not propagate this anti-pattern any further than it's
> already gone.
> 
> --
> Dave
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160331/74d81dde/attachment.html>


More information about the swift-evolution mailing list