[swift-evolution] Keyword for protocol conformance

[Charles Srstka]

> On Aug 24, 2016, at 1:20 AM, Robert Widmann <devteam.codafi at gmail.com> wrote:
> 2016/08/23 20:52、Charles Srstka <cocoadev at charlessoft.com <mailto:cocoadev at charlessoft.com>> のメッセージ:
> 
>>> On Aug 23, 2016, at 10:34 PM, Robert Widmann <devteam.codafi at gmail.com <mailto:devteam.codafi at gmail.com>> wrote:
>>> 
>>> 2016/08/23 15:29、Charles Srstka <cocoadev at charlessoft.com <mailto:cocoadev at charlessoft.com>> のメッセージ:
>>> 
>>>>> On Aug 23, 2016, at 2:33 PM, Robert Widmann via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>> 2016/08/22 14:30、David Cordero via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> のメッセージ:
>>>>> 
>>>>>> 
>>>>>> The problem:
>>>>>> At the moment, looking at the code of a class or a struct implementing a protocol, it is hard to know what methods are actually implementing the protocol and what other methods are just part of the code of the class or struct.
>>>>>> 
>>>>> 
>>>>> That seems like a feature, not a bug.  Why should I as an author care whether a method contributes to a protocol conformance or not if the compiler can tell me that kind of information itself?
>>>> 
>>>> Being able to reason about your code, what it does, and what it’s for is undesirable?
>>> 
>>> That's not an answer to the question I asked.  Why is this significant enough to warrant an entire keyword?  The clutter of a whole keyword that does nothing but wait for a developer to make a source-compatible binary-breaking change to an interface does not seem worth it.  Maybe you can convince me otherwise. 
>> 
>> Same reason overriding a class method warrants a keyword. It expresses the purpose more clearly, and allows the compiler to catch mistakes for us.
>> 
> 
> That's just it: The class of mistakes one can make by not being explicit about overrides is significantly more dangerous than the class of mistakes caused by dead code leftover from trimming protocols.

I am in the middle of a large refactor of code that was originally Objective-C and then Swift written like Objective-C, to more idiomatic protocol-oriented Swift. I am finding that in Swift’s POP idiom, protocols with overrides are serving very nearly the same purpose that overrides were serving in the old design; hence, I don’t really think either is more or less dangerous than the other.

>>>>>> ```
>>>>>> protocol MyProtocol {
>>>>>>     func myMethod() -> String
>>>>>> }
>>>>>> 
>>>>>> class MyClass: MyProtocol {
>>>>>> 
>>>>>>     conform func myMethod() -> String {
>>>>>>         return "Yuhuuu,I am conforming \\o// <smb://o//>"
>>>>>>     }
>>>>>> 
>>>>>>     func whatever() {
>>>>>>         print("I am a boring method and I don't conform anything")
>>>>>>     }
>>>>>> }
>>>>>> ```
>>>>>> 
>>>>>> It would be something similar to the current keyword `override` but for protocols. 
>>>>>> 
>>>>>> Apart from improving code readability, It would allow the detection, in compilation time, of errors due to code evolution. For example redundant methods that no longer conform anything once the requirement is removed from the protocol for whatever reason.
>>>>> 
>>>>> If you make a breaking change to a protocol like this, you should have gone through a deprecation cycle to indicate to your clients the appropriate changes you're going to make to the protocol.  This aspect of the change seems to if not encourage, highlight, bad behavior.
>>>> 
>>>> What if it’s your own code and all the callers are internal? What if you’re still developing the protocol and haven’t released the API interface yet?
>>> 
>>> Then your concerns are local enough that you know where all implementations of the protocol lie and whether they require deletion or not.  The point about deprecation cycles still stands in all the cases you mention.  Just because the interface is private doesn't mean you can't take responsibility for keeping it as clean as you can.
>>> 
>>>> 
>>>> Charles
>>>> 
>>> 
>>> tl;dr It seems like all of this can be subsumed by us warning about dead code.
>> 
>> Did you look at my examples earlier in the thread? Neither of those would be caught by warning about dead code.
> 
> The example involving the default implementation is most compelling, but it indicates that your proposed solution should focus on the protocol extension and not the implementing declaration.  Perhaps reusing one of our existing keywords can help here
> 
> protocol P {
>   func foo() {}
> }
> 
> extension P {
>   default func foo() {}
> }
> 
> struct S: P {}
> 
> Of course, this change would be potentially source-breaking either way - I don't like the sound of an "optional keyword”.  

I can come up with a similar example without the mistake being in the extension, though:

protocol P {
	func foo() {}
}

extension P {
	func foo() { print(“Default Behavior”) }
}

struct S: P {
	func foo() { print(“Specific Behavior”) }
}

So far, so good. But now I realize that the original protocol needs an argument:

protocol P {
	func foo(bar: String) {}
}

extension P {
	func foo(bar: String) { print(“Default Behavior; bar is \(bar)”) }
}

struct S: P {
	func foo() { print(“Specific Behavior”) } // Whoops, forgot to update this method, and now it won’t get called—and we of course won’t see the carnage until runtime.
}

> Either way, we can all agree we need better diagnostics around these cases.

No doubt.

Charles

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160824/236737b0/attachment.html>