SE-0376 (second review): Function back deployment

[John_McCall]

I'm sorry for the relatively late feedback here; I had meant to post this earlier.

Here's Allan's argument for why @backDeployed requires @available from the previous thread:

@tshortli

This restriction is not strictly necessary but I do think it can help with clarity of intent. We have found over time that allowing API owners to omit availability entirely from public declarations in library modules is a nuisance because it's too easy to forget to add availability to new APIs when it is necessary to do so for correctness. We have other tooling approaches that can address that, though.

This is a classic case of proving too much. Nothing in this is specific to back deployment or even mentions it. It is, very plainly, an argument that there's a pervasive problem where the developers of libraries with stable ABIs are forgetting to add @available to all of their ABI-exposed APIs.

I completely sympathize with this problem, and we should take action to address it. There are two obvious ways to do so. One would be to add ABI checking as part of the standard build process, which is building on the tooling that Allan is talking about; there are a lot of good reasons to pursue that, but it's a longer-term thing. The second is to simply require all ABI-exposed APIs in ABI-stable libraries to have @available attributes, maybe with some new spelling (@available(*)?) to explicitly say that an API has no availability restrictions.

Neither of these solutions is specific to @backDeployed functions, and the restriction on @backDeployed functions does not make any significant impact on the problem. In my opinion, Swift should not address this in such a piecemeal way. This restriction should be removed from this proposal, and then we should solve the problem for real.