[swift-evolution] Proposal: Split extensions into implementing methods and adding static functions Was: [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

[David Waite]

> On May 3, 2017, at 2:09 AM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On May 3, 2017, at 12:25 AM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 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
> 
> 
> 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? 

Extension methods are not explicitly part of the protocol requirements, so having them overridable by default based on a type having a method or property with a matching signature is basically duck typing.

A hypothetical example, but if swift didn't define "filter(_)" as part of Sequence, it might mean that an extension adds filter with the predicate indicating that the value is included, while my custom sequence defined a filter method where true from the predicate means the value should be 'filtered out'. Both methods would wind up having identical signatures. Generic algorithms written under the concept that 'filter', added by an extension, is now part of the 'Sequence' contract, would be quite confused that sometimes the behavior of their algorithm reverses.

That method implementations which are not part of the protocol definition define functionality around use of a protocol rather than extending the protocol requirements can be confusing, but to me it has always seemed correct. To have those methods be part of the protocol requirements is changing the protocol requirements.

I tried pitching a proposal a few months ago which attempted not to change the rules but to have the code declare intent and compiler warn if the declared intent seemed wrong. I was surprised it got very little interest. Right now, we have an issue where overriding a class method gives you a nice error if you fat-finger part of the signature, but implementing a protocol with extensions providing default implementations does nothing (either when declaring the protocol extension or implementing the protocol within your type)

-DW
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170503/795ec85c/attachment.html>