<div dir="ltr">-1<div>I hope that default implementations living in the protocol will address this. I would even prefer to move in 'the other direction' and have optional methods on protocols come into swift as default implementations.</div><div>TJ</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Apr 2, 2016 at 6:07 AM, Brent Royal-Gordon via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Protocol requirements with default (no-op) implementations already satisfy that design goal, no?<br>
<br>
</span>Kind of. If I may steelman* optional members for a moment...<br>
<br>
In cases where a default implementation would do, the default implementation will usually also be the behavior you want for a nil instance, but there's no convenient way to share logic between the two. For example, consider this:<br>
<br>
protocol UITableViewDelegate {<br>
...<br>
func tableView(_ tableView: UITableView, heightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat<br>
}<br>
extension UITableViewDelegate {<br>
func tableView(_ tableView: UITableView, heightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat {<br>
return tableView.rowHeight<br>
}<br>
}<br>
<br>
class UITableView {<br>
...<br>
private func addRow(at indexPath: NSIndexPath) {<br>
...<br>
cell.size.height = delegate?.tableView(self, heightForRowAtIndexPath: indexPath) ?? rowHeight<br>
...<br>
}<br>
...<br>
<br>
You have to duplicate the default logic both in the default implementation and at the call site, but there is no convenient way to share it—the extension method can't call into an expression at some call site, and contrarily the call site can't invoke the default logic from the extension.<br>
<br>
If the method were optional, then optional chaining would solve this problem for us:<br>
<br>
protocol UITableViewDelegate {<br>
...<br>
optional func tableView(_ tableView: UITableView, heightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat<br>
}<br>
<br>
class UITableView {<br>
...<br>
private func addRow(at indexPath: NSIndexPath) {<br>
...<br>
cell.size.height = delegate?.tableView?(self, heightForRowAtIndexPath: indexPath) ?? rowHeight<br>
...<br>
}<br>
...<br>
<br>
This way, there is only one source of default behavior: the call site.<br>
<br>
I'm also concerned by the thought of just how many sub-protocols we might end up with. When I try to fully factor NSTableViewDelegate (as it currently exists in the headers), I end up with ten protocols:<br>
<br>
NSTableViewDelegate<br>
- tableView:willDisplayCell:forTableColumn:row:<br>
<br>
NSTableViewLayoutDelegate: NSTableViewDelegate<br>
- tableView:heightOfRow:<br>
<br>
NSTableViewRowSelectionDelegate: NSTableViewDelegate<br>
- tableView:shouldSelectRow:<br>
- selectionShouldChangeInTableView:<br>
- tableViewSelectionIsChanging:<br>
- tableViewSelectionDidChange:<br>
- tableView:shouldTrackCell:forTableColumn:row: (10.5)<br>
- tableView:selectionIndexesForProposedSelection: (10.5)<br>
<br>
NSTableViewTypeSelectDelegate: NSTableViewDelegate (10.5)<br>
- tableView:typeSelectStringForTableColumn:row:<br>
- tableView:nextTypeSelectMatchFromRow:toRow:forString:<br>
- tableView:shouldTypeSelectForEvent:withCurrentSearchString:<br>
<br>
NSTableViewToolTipDelegate: NSTableViewDelegate<br>
- tableView:toolTipForCell:rect:tableColumn:row:mouseLocation:<br>
<br>
NSTableViewColumnDelegate: NSTableViewDelegate<br>
- tableView:shouldEditTableColumn:row:<br>
- tableView:shouldSelectTableColumn:<br>
- tableView:mouseDownInHeaderOfTableColumn:<br>
- tableView:didClickTableColumn:<br>
- tableView:didDragTableColumn:<br>
- tableViewColumnDidMove:<br>
- tableViewColumnDidResize:<br>
- tableView:sizeToFitWidthOfColumn: (10.6)<br>
- tableView:shouldReorderColumn:toColumn: (10.6)<br>
<br>
NSTableViewCellExpansionDelegate: NSTableViewDelegate (10.5)<br>
- tableView:shouldShowCellExpansionForTableColumn:row:<br>
<br>
NSTableViewCustomCellDelegate: NSTableViewDelegate (10.5)<br>
- tableView:dataCellForTableColumn:row:<br>
- tableView:isGroupRow:<br>
<br>
NSTableViewCellViewDelegate: NSTableViewDelegate (10.7)<br>
- tableView:viewForTableColumn:row:<br>
<br>
NSTableViewRowViewDelegate: NSTableViewDelegate (10.7)<br>
- tableView:rowViewForRow:<br>
- tableView:didAddRowView:forRow:<br>
- tableView:didRemoveRowView:forRow:<br>
- tableView:rowActionsForRow:edge: (10.11)<br>
<br>
Some of these are probably unnecessary; they could be merged into NSTableViewDelegate and given default implementations. But at least a few of them would be very much needed. Would users be able to navigate this mess? Would they discover the features tucked away in sub-protocols? I'm just not sure.<br>
<br>
And of course the safety issues that make optional protocol members dangerous in Objective-C don't exist in Swift. Swift will force you to test for the presence of an optional member; you can't carelessly call one.<br>
<br>
(Incidentally, resilience might also benefit from supporting optional protocol members and adding a `public(optional)` feature which made all call sites outside the resilience domain treat all members as optional. You could then mark protocols meant to be called only by clients inside the resilience domain—like data sources and delegates—with `public(optional)` and gain the ability to delete obsolete members.)<br>
<br>
<br>
<br>
* Steelmanning is the opposite of strawmanning.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>