[swift-evolution] Keyword for protocol conformance

[Xiaodi Wu]

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

> On Aug 26, 2016, at 3:39 AM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
>
> 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.
>
>
> We were speaking of extending a protocol.
>

That is not exactly what Brent was speaking of. We are talking about this
scenario:

File A:

```
internal struct S {
  func foo() { }
}
```

File B:

```
private protocol P {
  func foo()
}

extension P {
  func foo() { }
}

// With your proposal, I can't write the following line:
extension S : P { }
// In file A, S.foo() isn't overriding anything, so I can't add `override`
// But in file B, S can't conform to P,
// because S.foo() isn't overriding P.foo() without `override` in file A
```

This means that either 1) the method we add lives only in the extension, is
> statically dispatched, and thus does not exist to code that cannot see the
> extension, or 2) the code that cannot see the extension has been written as
> if the extension did not exist, and thus must already have another
> implementation of the method. In neither case does the extension affect the
> behavior of code that cannot see it.
>
> If the protocol is private, then your internal type cannot see it. The
> internal type, which lives in complete blissful ignorance of the private
> protocol, can coincidentally implement one of the methods, but it is not
> conforming to the protocol in doing so, and thus does not have any need of
> adding a keyword to indicate that it is so conforming. If the match in
> nomenclature is more than coincidental, the intention falls on the private
> protocol, not the internal type.
>
> The point of the keyword is to clarify *intentions.* If I am declaring my
> type as conforming to a protocol, and I am implementing methods that are
> required by the protocol, I should tell the compiler that the purpose of
> these methods is to satisfy the protocol. If I am implementing a protocol
> method that already has a default, I should indicate that I’m doing that on
> purpose, as well. If I *am not conforming* to the protocol and somebody
> *else* is adding conformance in an extension, then it’s not my problem and
> the person doing the conforming should be the one to declare their intent.
>
> Charles
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160826/c1607359/attachment.html>