[swift-evolution] Keyword for protocol conformance

[Xiaodi Wu]

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

> 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>
>  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.c
>> om> 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?
>
>
> 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.
>

That is incorrect. If it's a protocol requirement, it's dynamically
dispatched. If I conform an internal type to a private protocol and use
that type in the same file where the protocol is defined, that type
conforms to the protocol. You would have no way of appending the `override`
keyword to the relevant overrides without making the protocol internally
visible.

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/5957322c/attachment.html>