> On Aug 22, 2016, at 5:41 PM, Xiaodi Wu <[email protected]> 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);
You don’t get any error at all if there’s a default value.
protocol P {
func doSomething()
}
extension P {
func doSomething() { print(“Do This Thing”) }
}
struct S: P {
func doSomthing() { print(“Do This Instead”) } // Whoops, doesn’t get
called. And we don’t find out until mysterious behavior occurs at runtime.
}
If there were a way to tell the compiler that the function was meant to satisfy
a protocol, we could prevent the mistake above from occurring.
> (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?
The fact that implementing protocol requirements that have default values is,
in effect, stringly typed.
Charles
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
