The example demonstrated by the proposal does not make it particularly clear, but this seems like a useful feature towards making APIs back-portable by 1st or 3rd parties.
For a trivial example, I could think of ways to make SwiftUI’s refreshable(action:)
modifier available (albeit in a renamed form[1]) to older platform versions without resorting to SwiftUI._ConditionalContent
the actual return type of the modifier:
extension View {
// Note: no `@ViewBuilder` here!
@available(iOS 14.0, *)
func refreshable_(action: @escaping @Sendable () async -> Void) -> some View {
if #available(iOS 15.0, *) {
return self.refreshable(action: action)
}
// Something like https://github.com/siteline/SwiftUI-Introspect#scrollview
...
}
}
(If the function interface to backport contains data types or protocols unavailable to older targeted platform versions, however, then I'm afraid something more is needed than this proposal alone.)
- What is your evaluation of the proposal?
+1
- Is the problem being addressed significant enough to warrant a change to Swift?
Yes.
- Does this proposal fit well with the feel and direction of Swift?
It seems like a natural extension to the rules about #available
(and #unavailable
).
- If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
N/A
- How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Quick reading, but also gave it a quick try on the latest main
snapshot toolchain using iOS Simulator 14.5 and 15.5.
Completely shadowing the existing implementation would further need a way for the shadowing function’s body to refer back to the shadowed one in the
SwiftUI
module in a qualified form, say,return `SwiftUI.View`.refreshable(action: action)
. Something similar was discussed but mainly for module-level symbols, not members, in Pitch: Fully qualified name syntax. ↩︎