[swift-evolution] Keyword for protocol conformance

[Xiaodi Wu]

On Fri, Aug 26, 2016 at 1:53 AM, Charles Srstka <cocoadev at charlessoft.com>
wrote:

> 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
> > 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?
>
>
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160826/833ea1a1/attachment.html>