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 <[email protected]> wrote: > On Aug 22, 2016, at 5:19 PM, Xiaodi Wu via swift-evolution < > [email protected]> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
