<div>I should add, the reason final is inapt in this situation is at least twofold.</div><div><br></div><div>The first is, of course, that this makes it impossible to guarantee source compatibility and offer additional functionality in a protocol extension, since any such addition would break unknowable amounts of existing code. Consider if we wanted to add a commonly requested convenience function to Collection in the standard library. Since it is so commonly useful and doesn't currently exist in the standard library, it is very likely that numerous people have written their own extensions for one or more concrete types (say, Array). It would therefore not be possible to add this to the standard library as an extension on Collection unless (a) we pick a silly name that we know no one would call this function, which is counterintuitive, as ideally we want to pick an obvious name that everyone would call this function; or (b) we make it a protocol requirement with a default implementation, which is both not what it really is (conceptually, it's not something that all things need to do in order to be a bona fide collection, for which we can give just a placeholder default; rather, it's a neat thing that all bona fide collections can do, and we are implementing the specific neat thing and not a placeholder to be refined later) and it would run into the second issue.</div><div><br></div><div>The second issue to do with why final is inapt relates to the fact that protocols are not hierarchically inherited but are meant to be composable without the problems of multiple inheritance. For instance, the following is possible--and should be:</div><div><br></div><div>```</div><div><div><div>protocol P {</div><div>}</div></div><div><br></div><div>extension P {</div><div> func f() {</div><div> print("42")</div><div> }</div><div>}</div></div><div><br></div><div><div>protocol Q {</div><div>}</div></div><div><br></div><div><div>extension Q {</div><div> func f() {</div><div> print("43")</div><div> }</div><div>}</div></div><div><br></div><div><div>struct S : P, Q {</div><div>}</div></div><div><br></div><div>let s = S()</div><div><br></div><div>(s as P).f()</div><div>(s as Q).f()</div><div>```</div><div><br></div><div>If f were either final or a protocol requirement, barriers would arise due to clashing definitions. Again, this has source compatibility implications. It also places limits on the composability and evolution of protocols where today there aren't any.</div><div><br></div><div><br><div class="gmail_quote"><div>On Wed, May 3, 2017 at 04:00 Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Well, the revised integer protocols that were just approved do just that: some functions are defaults and others cannot be overridden. Smart shifts, for example, are deliberately not customization points. This is also the case for Equatable: you get to define ==, but != is not a protocol requirement and cannot be overridden. A very long list of algorithms on Sequence and Collection are also implemented in this way (contains, elementsEqual, enumerated, first, flatMap, lexicographicallyPrecedes, min, max, reduce, reversed, sorted...). So, at least equatables, numbers, sequences, and collections depend on this design--I'd call that pervasive. And these are just the protocols I've worked with in the last two days; I haven't even looked at the documentation for others.</div><div><br></div><div>It serves a real purpose. As has been said before, protocols are not mere bags of syntax. However, the compiler cannot enforce arbitrary semantic requirements. This feature allows protocols to guarantee the semantics of particular members. It is how you can know with complete certainty while writing a generic algorithm that a == b implies !(a != b) for all equatable values. Conceptually, protocol extension methods are exactly what their name suggests: they are definitive implementations of generic algorithms that make use of the guarantees of a protocol; they are not placeholder implementations of a requirement that constitutes a part of the protocol itself. How else would you provide functionality that extends a protocol as you would a type?</div><div><br></div><div>And no, we wouldn't prefer to just mark all of those members as "final". That was just settled in SE-0164; once upon a time, it was required to do so, but that was actually tried and backed out, and now the last vestiges of that legacy have literally just been slated for removal with community approval.</div><div><br></div><div><br><div class="gmail_quote"><div>On Wed, May 3, 2017 at 03:09 Brent Royal-Gordon <<a href="mailto:brent@architechies.com" target="_blank">brent@architechies.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On May 3, 2017, at 12:25 AM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-7832693259131535904m_-7953612460858156327Apple-interchange-newline"><div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">I definitely agree that it's a feature that _can_ be used unwisely, but the fact remains that it _is_ used pervasively in the standard library, and deliberately</span></div></blockquote></div><div><br></div></div><div style="word-wrap:break-word"><div>I'm not so sure that's true. Which standard library protocols intentionally depend upon certain parts to not be overridable? Are they so pervasive that we wouldn't prefer to just mark those members that need it with a `final` keyword? If John McCall woke up tomorrow with some genius idea of how to make extension methods overridable with zero overhead, would we choose to keep the current design? </div><div><br></div><div>That's not to say the proposal at hand is a good idea, but I think you're overselling the current design.</div></div><div style="word-wrap:break-word"><br><div>
<span class="m_-7832693259131535904m_-7953612460858156327Apple-style-span" style="border-collapse:separate;color:rgb(0,0,0);font-family:Helvetica;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:auto;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><div style="font-size:12px">-- </div><div style="font-size:12px">Brent Royal-Gordon</div><div style="font-size:12px">Architechies</div></div></span>
</div>
<br></div></blockquote></div></div></blockquote></div></div>