One thing which I haven't covered in the Future Directions section of the proposal yet but seems like it would be a logical next step would be back deployment of protocol conformances, e.g.
@available(toasterOS 1.0, *)
@backDeploy(toasterOS 2.0, *)
extension Toast: Hashable {
// ...
}
There are plenty of backend details to work out about how this would be accomplished, but there are also some design questions we could ask now about how the proposed attribute would be extended to cover this case. Allowing the attribute to be applied to the extension declaration seems like the natural way to do this, but that raises some questions like whether you should be able to back deploy extensions in general. We'd also need to think about how to handle extension members with heterogenous availability or back deployment. The conservative approach would be to require annotations on every member for maximum clarity, but it would be verbose.
EDIT: I found a thread from a few years ago where @jrose discussed back deployment for protocol conformances.
I think "back deploy" is a fairly well established term of art in the Swift community (there are 35 hits when I search this forum for the phrase "back deploy"). This is the first time I've heard the term polyfill myself, but perhaps it feels more familiar to others (EDIT: I searched for it here on the forums as well and it also comes up plenty, though not as frequently; I guess this is just my ignorance!) As for shim, I think it could work when combined with "compatibility", but to me "back deploy" feels like a more precise description of what the attribute accomplishes.