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

[Chris Lattner]

> 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. 

Protocol requirements with default (no-op) implementations already satisfy that design goal, no?

-Chris

> 
> 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/1c474316/attachment-0001.html>