[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

[Xiaodi Wu]

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.

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?

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.


On Wed, May 3, 2017 at 03:09 Brent Royal-Gordon <brent at architechies.com>
wrote:

> On May 3, 2017, at 12:25 AM, Xiaodi Wu via swift-evolution <
> 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?
>
> That's not to say the proposal at hand is a good idea, but I think you're
> overselling the current design.
>
> --
> Brent Royal-Gordon
> Architechies
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170503/4250dfe1/attachment.html>