> On May 3, 2017, at 2:09 AM, Brent Royal-Gordon via swift-evolution
> <[email protected]> wrote:
>
>> On May 3, 2017, at 12:25 AM, Xiaodi Wu via swift-evolution
>> <[email protected] <mailto:[email protected]>> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
