[swift-evolution] Keyword for protocol conformance

[Charles Srstka]

> On Aug 26, 2016, at 2:22 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> On Fri, Aug 26, 2016 at 1:53 AM, Charles Srstka <cocoadev at charlessoft.com <mailto:cocoadev at charlessoft.com>> wrote:
>> On Aug 25, 2016, at 11:48 PM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto: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.
> 
> I made the same argument eight months ago:
> 
> > Another option might be to allow imported definitions to be used by a conformance without the `override` marking to support retroactive modeling while requiring definitions in the same module as the conformance to explicitly specify the `override`.
> 
>  But Brent Royal-Gordon had a good point: 
> 
> But the same problem exists if you want to do this to `internal` types using a `private` protocol. There you *could* make the protocol `internal` and call `override` in all the right places, but if the protocol is an implementation detail of one particular file, why should you?

If the protocol is private, than to code outside that file, the protocol effectively doesn’t exist, since code in protocol extensions is statically dispatched (this is also true to code in your hypothetical library). So no need for “override” there.

If the protocol is internal, than code elsewhere in your app can see it, and thus they should have to override, for the same reason that if you added a superclass method that some subclass was already using, you’d need to add “override”.

Charles

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