[swift-evolution] Keyword for protocol conformance

[Xiaodi Wu]

On Thu, Aug 25, 2016 at 11:05 PM, Charles Srstka <cocoadev at charlessoft.com>
wrote:

> On Aug 25, 2016, at 10:24 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
>
> Yes, and it's covered in those previous threads. In brief, not all
> retroactive modeling involves extending a type:
>
> * A vendor supplies you with a closed-source library with a struct S that
> conforms to standard library protocol P.
>
> * Protocol P requires a method named foo(), so struct S has its own
> implementation of foo().
>
> * You extend protocol P by adding a new default implementation of foo().
>
> This cannot be done if a keyword is required for overriding a default
> implementation. There is also nowhere for you to append any sort of "retro"
> keyword anywhere, because no part of your own code extends S in any way.
>
> Please, please take the time to study the previous threads; we should not
> be re-playing existing discussions four or five times on this list.
>
>
> How is this a problem, though? The implementation of foo() in S will not
> break, because it’s already been compiled in. The change will only affect
> code that is subsequently compiled with your extension of P in place. And
> it’ll be doing its job; making sure that your code to implement the
> protocol is there deliberately, and preventing you from accidentally
> mistyping the method name and thus silently failing to override the default
> implementation.
>

So you're saying that the compiler should let you compile your extension of
P, even though it knows that the default implementation of `foo()` is not
explicitly overridden by S. Fine.
Now suppose the library is not closed-source; you're including it in your
project and compiling it along with your own code. Are you supposed to fork
the library?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160825/af9a1cfc/attachment.html>