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

[David Waite]

+1

We need to support optional methods in @objc protocols because it is required for interoperability. However, there are in my experience only reasons for an optional protocol method:

- There is a very common default behavior for a delegate (such as return immediately with a value of 0/nil/false) which would be a burden to require everyone to implement. We can instead accomplish this with protocol extensions

- The absence of a method in a delegate indicates a behavior that is otherwise impossible for the delegate to implement. The easiest example of this would be  tableView:heightForRowAtIndexPath:, where the absence triggers an optimization where UITableView.rowHeight is used for all math, and its presence means that performance will be degraded, and the delegate will be called repeatedly for every single index path in order to figure out the table positioning/scroll height. I believe this has been shown to be much better solved via an optional additional protocol conformance to indicate that you are supporting a different ‘class’ of behavior, in this case that might be something like UITableViewVaribleHeightDelegate.

I’d hate for there to be a push for optional protocol methods just because it can be confusing which methods are required in swift protocol implementations (vs defaulted by a protocol extension).

-DW

> On Mar 31, 2016, at 12: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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160331/a3ff0657/attachment.sig>