<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
1. Do people really want this?<br></blockquote><div><br></div><div>Yes, if for no other reason than that the current behavior (imho) violates the principle of least surprise - the surprising part being that the behavior is different than other method calls. Further, there is no way to know at the call site what the behavior is going to be, hindering readability.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2. People familiar with the implementation of protocol witnesses: is this feasible?<br></blockquote><div><br></div><div>I am not familiar with this so I can&#39;t comment specifically, but I would just like to mention that (with apologies to whoever might eventually have to implement this) the compiler is meant to serve the programmer, not the other way around.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">3. Do people want the current non-overridable, statically-dispatched protocol extension members available as an option?<br></blockquote><div><br></div><div>Sure, why not? I would prefer it not be the default behavior, though. It should be triggered by some keyword (final, default, etc) in the protocol extension.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">4. Should this be proposed alongside other changes that would reduce the difference between a protocol and a protocol extension, like allowing default implementations in the protocol declaration?<br></blockquote><div><br></div><div>I don&#39;t feel strongly one way or the other about this.</div><div><br></div><div>Thanks!</div><div>Andy </div></div></div></div>