Since Date.now is just an another way to call Date.init(), I expected it to be back deployed. But it's currently only available over iOS 15 and over. Was there a spesific reason for this since some other functions (2 inits to be exact) are back deployed?
The @backDeployed attribute and its functionality appeared later than iOS 15 (16.4 to be exact), and it appears no one has since strongly suggested fixing the oversight – or submitted a patch.
Is it okay to drop the OS version after release if it gets marked @backDeployed? If so, I can open a pull request.
It is ABI on Apple platforms, so the availability must remain. I think it’s doable, but I’ve never tried. If you open a pr, we can iterate as needed.
3 Likes
When you retroactively add @backDeployed to an existing declaration, the @available attribute should also be updated to reflect the OS version that the declaration supports back deployment to (which could be "all versions", in which case dropping the @available attribute entirely is fine).
In this case, the declaration was this before:
/// Returns a `Date` initialized to the current date and time.
@available(macOS 12, iOS 15, tvOS 15, watchOS 8, *)
public static var now : Date { Date() }
I'd expect it to look like this after:
/// Returns a `Date` initialized to the current date and time.
@backDeployed(before: macOS 12, iOS 15, tvOS 15, watchOS 8)
public static var now : Date { Date() }
No @available is needed anymore because the only declaration used in the body is init(), which is always available when Date is available, so now should be that available too.
2 Likes
I opened the pull request.
1 Like