[swift-evolution] Keyword for protocol conformance

Xiaodi Wu xiaodi.wu at gmail.com
Fri Aug 26 15:02:07 CDT 2016


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

> On Aug 26, 2016, at 2:49 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
>
> Sorry, I was referring to my original example: S is in a different file
> from P and has its own implementation of foo(), and P has its own default
> implementation of foo(). I assumed you simplified the example above to
> discuss the generated interface. I didn't realize you were moving on to a
> different example.
>
>
> You are correct; it was a simplified example to discuss the generated
> interface. I was confused by your objection’s proximity to it; sorry for
> the noise.
>
>
>>> In any case, you have not solved the problem, which has nothing to do
>>> with whether something is "reasonable to know": when a default
>>> implementation A is overridden by implementation B, implementation A may be
>>> visible only in a *more restricted* access scope than implementation B.
>>> (This is not the case with overriding superclass members in subclasses.) It
>>> can be perfectly "reasonable to know" about both A and B, but there is
>>> still no way you can indicate this knowledge by appending a keyword to the
>>> declaration for implementation B if the access scope for implementation A
>>> is unutterable where B is declared.
>>>
>>>
>>> Could you provide an example of code where this would present a problem?
>>>
>>
>> I'm still talking about the same example. How do you rationalize your
>> statement that no keyword is needed because it's not "reasonable to know"
>> about both S and P when compiling the file in which P is declared?
>>
>>
>> When compiling the file in which P is declared, you would add the
>> keyword. Code outside this file that happened to define methods named foo()
>> would not, since they would not be consciously conforming to the protocol.
>>
>
> What keyword could you add to P, when the overriding member is in S?
>
> File A:
> ```
> internal struct S {
>   func foo() { }
> }
> ```
>
> File B:
> ```
> private protocol P {
>   func foo()
> }
>
> extension P {
>   func foo() { }
> }
>
> extension S : P { }
> ```
>
> Where do I append your proposed keyword? Or, how do you rationalize its
> not being required on the basis of "reasonable to know"?
>
>
> File A does not need the keyword, since it is not implementing P by adding
> foo() and cannot be expected to know about it, and thus it’s rather
> arguable to say that it is “overriding” anything. The extension that
> conforms S to P declares no methods, so it is clear that this is meant to
> be retroactively conforming, so I am not convinced a keyword is needed
> here. However, there is room for debate here, and if we determined that a
> keyword should be required, then I would say it should go in the extension
> that conforms S to P, since that is where the “problem” occurs.
>
> If S had been declared in File B, however, there would be a keyword
> attached to its declaration of foo(), since the information that S conforms
> to P, as well as the fact that foo() is a requirement of said protocol,
> would all be visible in the current scope.
>

Why? S.foo() is visible throughout the module, but outside this file,
S.foo() doesn't override anything. Why should it be marked as an `override`
when, as you say, the generated interface shows no sign of conformance to P?
In addition, how would you justify a requirement to fiddle with these
keywords when someone simply refactors an internally visible type with no
private members from one file to another? Your proposed rule just broke
copy-and-paste...


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


More information about the swift-evolution mailing list