@backDeployed is operating as an override instead of only for use in unsupported platforms versions

[Karl]

@tshortli

I think you have misinterpreted what the @backDeployed attribute does and what it is meant to be used for. @backDeployed was designed for use in the implementation of frameworks that ship with an OS. The attribute is not designed give you a way to provide your own polyfills for arbitrary functions in the SDK

FWIW, this is exactly the reason I argued against making @backDeployed a public-facing feature. It's a good feature, but only Apple's SDK engineers have meaningful reason to use it.

@Karl

The issue is not that it is "primarily an Apple platform concern" - it is that it is exclusively meaningful for engineers creating Apple's SDK libraries. In that respect, it could not be more different to the availability system.

Joe Programmer, writing code which will run on an Apple platform, needs to know about availability. They may need to conditionalise calling certain APIs using if #available, or annotate their own APIs with @available if they absolutely depend on an availability-limited platform API.

Joe will never have to write @backDeploy. He has no meaningful way to use that feature, because there is no chance whatsoever that code compiled against a newer interface will load an older version of his library at runtime. That is a problem that only Apple's SDK engineers need to worry about.

We should definitely clarify its intended use in documentation. In fact, I would go even further and disallow it from regular swift code (so misunderstandings like the one in this thread result in a compiler error), unless one passes in a special compiler flag to enable it.

If users are attaching @backDeploy to their code, they're just making a mistake. Why would we let them do that?