Well one missed aspect is that the delegator can test if the delegate responds to the method and modify its logic to adjust to the reality (which could have reasonable optimization hanging off it). If you depend on default no-op you don't get that ability (at least as "easily"). ...it of course is intertwined with the runtime capabilities of objective-c.<br><br><br><div class="gmail_quote"><div dir="ltr">On Fri, Mar 4, 2016 at 9:16 AM Erica Sadun via swift-dev <<a href="mailto:swift-dev@swift.org">swift-dev@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Mar 4, 2016, at 9:25 AM, Dave Abrahams via swift-dev <<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>> wrote:<br>
><br>
><br>
> on Fri Mar 04 2016, Simon Pilkington <swift-dev-AT-swift.org> wrote:<br>
><br>
>> This seems like a strange/unrelated restriction on what is quite a useful feature.<br>
><br>
> ...or an abomination. What sense does “optional requirement” make,<br>
> after all?!<br>
><br>
<br>
However oxymoronic, I kind of get the point. If you want default no-op behaviors, with<br>
the option to override, which is what optional Objective-C requirements really are, just<br>
create protocol extensions.<br>
<br>
extension MyProtocol {<br>
func optionalMember() {} // nothing to do<br>
}<br>
<br>
This guarantees that the member exists, can be called by all consumers, but that there's a<br>
default in place that frees the conforming type from actually having to implement anything<br>
unless it really wants to.<br>
<br>
-- E<br>
<br>
<br>
_______________________________________________<br>
swift-dev mailing list<br>
<a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-dev" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-dev</a><br>
</blockquote></div>