That's a good point. Since you're proposing an optional keyword, though, aren't you describing a linter functionality? On Mon, Aug 22, 2016 at 18:25 Charles Srstka <[email protected]> wrote:
> 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
