[swift-evolution] Keyword for protocol conformance

[Charles Srstka]

> On Aug 25, 2016, at 11:48 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> On Thu, Aug 25, 2016 at 11:05 PM, Charles Srstka <cocoadev at charlessoft.com <mailto:cocoadev at charlessoft.com>> wrote:
>> On Aug 25, 2016, at 10:24 PM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto: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?

Even if the library is open-source, you'll presumably be building in as its own target, which will be including only library code and not your extension, and linking it into the application in a later stage of the build process.

Charles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160826/a2cd4edd/attachment.html>