[swift-evolution] Keyword for protocol conformance

[Charles Srstka]

> On Aug 26, 2016, at 2:34 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> internal struct S {}
> 
> private protocol P {
>     func foo()
> }
> 
> extension S: P {
>     func foo() {}
> }
> 
> - - - choose “Generated Interface” and you get: - - -
> 
> internal struct S {
> }
> 
> 
> extension S {
> 
>     internal func foo()
> }
> 
> - - -
> 
> While the extension is visible, the fact that it adds conformance to P is not. Therefore, as far as code outside this file is concerned, there is no conformance to P.
>  
> That's correct, but why should the compiler accept the code in this file, when both S and P are visible, and S is not overriding default implementations in P as it should? 

I am confused. Why should S, above, be required to override P’s default implementation of foo()?

> 
>> 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.

Charles

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