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

[Matthew Johnson]

> On Mar 31, 2016, at 5:51 PM, David Waite via swift-evolution <swift-evolution at swift.org> wrote:
> 
> +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.

+1.  I am not fully pleased with the design of the UITableViewDelegate and UITableViewDataSource protocols and this is one point that is problematic.  It makes it impossible to implement a generic delegate that might sometimes need to have variable row height, but in other cases should take the fast path.

> 
> 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
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution