[swift-evolution] Keyword for protocol conformance

[Charlie Monroe]

I don't see it as sub-par in this example (this actually happened to me):

@objc protocol Foo {
	optional func bar()
}

class FooImpl: Foo {
	func bar() { ... }
}

Now imagine that bar() gets renamed in the protocol to baz(). You get no warnings, nothing - since the bar() was optional (or can have default implementation as Chalers mentioned). FooImpl still conforms to Foo and bar() can live on there happily.

Yes, this could be solved by Xcode having a refactoring feature that works for Swift, or that you search & replace when renaming, but still doesn't solve when a 3rd party library does this and suddenly the behavior of your app changes completely. This goes against the compile-time safety Swift is about.

Currently, when you mark a method on a protocol as

@available(*, unavailable, renamed="baz")

you do not get any warnings either - perhaps that's the issue here. On the other hand, the naming may be completely coincidental and you can already have a method called bar() and it would then be impossible to conform to Foo unless you rename bar().

What I'd propose is not to make keyword optional. In case you implement the members declared by the protocol, mark it as @conforming (or conforming keyword?).

If it's retroactive modeling, redeclare the members. E.g.:

extension Bar: Foo {
	// The implementation will be taken from Bar's main implementation
	@conforming func bar()
}

But yeah, it's a bit of boilerplate...

> On Aug 23, 2016, at 12:41 AM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> 
> There's been agreement even from the core team that the quality of diagnostics when conforming to a protocol is sub-par.
> 
> The modified rule you propose has also been suggested before. The reason it doesn't help is that (1) if a method signature is mismatched accidentally due to a typo, you get a compilation error already because your type doesn't conform to the protocol (it's the quality of the error message that needs improvement); (2) otherwise, if your type fulfills all protocol requirements but also implements an additional method unnecessary for conformance, what is the harm that is being prevented by a compiler error?
> 
> On Mon, Aug 22, 2016 at 17:30 Charles Srstka <cocoadev at charlessoft.com <mailto:cocoadev at charlessoft.com>> wrote:
>> On Aug 22, 2016, at 5:19 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> This has been proposed before in the past by several others (myself being one of them).
>> 
>> The key problem is that it cannot accommodate retroactive modeling. That is, you would not be able to conform existing types, the code for which you do not control, to a protocol of your own design. Retroactive modeling is an essential feature of Swift protocol-oriented programming.
> 
> Then how about making the keyword optional? A method or property with the keyword before it would throw an error if it didn’t exist in one of the protocols your type implements. This way, if you intended a method to satisfy a protocol but left a typo in it, or you changed the protocol’s signature in a refactoring or something, you’d get notified instead of not finding out about it until runtime.
> 
> Charles
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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