<div style="white-space:pre-wrap">(Sorry I hate top posting but fighting with Google inbox to avoid it)<br><br>In delegation patterns it can be very helpful in terms of optimization (performance and memory) if the delegator can interrogate a delegate to know if certain delegation points are needed or not. I have code that has done this interrogation at delegate registration allowing potentially complex code paths and/or state maintenance to be avoided. It also could do impl caching to improve dispatch (did not support after registration "reconfiguring" delegates in this model purposely).<br><br>Under objective-c leveraging optional protocol methods and runtime checks for responds to those was one built-in way for that. It also could add boilerplate code to check before dispatch that was potentially error prone and cumbersome. ...hence why I often did the check and configuration at registration in my code often avoiding peppering code with dispatch checks.<br><br>Anyway not attempting to state anything for against this question about optional requirements in swift protocols. ...a handful of reasonable patterns exist in swift that allows one to achieve the same thing in safer and likely more performant ways.<br><br>-Shawn<br><br><br></div><div class="gmail_quote"><div dir="ltr">On Fri, Mar 4, 2016 at 9:38 AM Dave Abrahams <<a href="mailto:dabrahams@apple.com" target="_blank">dabrahams@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
on Fri Mar 04 2016, Shawn Erickson <shawnce-AT-gmail.com> wrote:<br>
<br>
> Well one missed aspect is that the delegator can test if the delegate<br>
> responds to the method and modify its logic to adjust to the reality (which<br>
> could have reasonable optimization hanging off it). If you depend on<br>
> default no-op you don't get that ability (at least as "easily"). ...it of<br>
> course is intertwined with the runtime capabilities of objective-c.<br>
<br>
All that testing puts too much burden on the client, IMO. It's much<br>
better to provide customization points with default behaviors that work<br>
sensibly when not overridden.<br>
<br>
><br>
> On Fri, Mar 4, 2016 at 9:16 AM Erica Sadun via swift-dev <<br>
> <a href="mailto:swift-dev@swift.org" target="_blank">swift-dev@swift.org</a>> wrote:<br>
><br>
>><br>
>> > On Mar 4, 2016, at 9:25 AM, Dave Abrahams via swift-dev <<br>
>> <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<br>
>> 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<br>
>> behaviors, with<br>
>> the option to override, which is what optional Objective-C requirements<br>
>> 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,<br>
>> but that there's a<br>
>> default in place that frees the conforming type from actually having to<br>
>> 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>
>><br>
<br>
--<br>
-Dave<br>
</blockquote></div>