Swift Framework Patch Proposal Pitch

January 17, 2016

After raising a ruckus about the thread on swift-evolution discussing making methods final by default, I was extremely pleased to see this proposal pitch shared by Joe Groff.

A lot of the discussion around the final/sealed-by-default issue focused on the ability in ObjC to extend frameworks or fix bugs in unforeseen ways. Framework developers aren’t perfect, and being able to patch a broken framework method can be the difference between shipping and not. On the other hand, these patches become compatibility liabilities for libraries, which have to contend not only with preserving their own designed interface but all the undesigned interactions with shipping apps based on those libraries. The Objective-C model of monkey-patchable-everything has problems, but so does the buttoned-down everything-is-static C++ world many of us rightly fear. However, with the work we’re putting into Swift for resilience and strong versioning support, I think we’re in a good position to try to find a reasonable compromise.

The essence of the idea is to provide specific, language-level support for declaring a patch to framework code from client code. Joe also sketches a corresponding mechanism for assisting framework authors in evolving their code while still supporting apps that rely on previous, buggy framework behavior.

There are lots of details that would need to be worked out, but mostly I’m gratified that Joe so clearly articulates the concerns that many of us in the app development community share.

Thanks, Joe!

Archive →