Refactoring protocols

Hey community,

for obvious reasons in frameworks, but also for testability in other projects, one uses protocols. Until you're really comfortable with them and declare them stable, you may from time to time refactor some methods in those protocols. This will be a pain in the ass for everyone using the framework, but sometimes, it's necessary.

To mitigate how painful it is to conform to a protocol, the author may decide to provide a default implementation. If you rename the default implementation along with your protocol requirement, all the users that are happy with the default implementation won't notice that anything happened. But how do you remember this? After all, it might be that you provide several default implementations based on different generic constraints, and the compiler won't yell at you if you forget to change it; it will only yell at downstream users of your framework who suddenly don't get conformance for free. What's your best practice?

2 Likes

Sounds like you could add a test for this. Define types that exercise the various generic constraints and ensure that you can call the expected protocol methods on them. The test module should fail to build if you forget to update something.

2 Likes
Terms of Service

Privacy Policy

Cookie Policy