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

[Yuval Tal]

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

>
> on Wed Mar 30 2016, Yuval Tal <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
> 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/befc3f21/attachment.html>