Type: New Feature
In the Swift Protobuf project (github.com/apple/swift-protobuf), we generate Swift code from .proto files. These .proto files contain messages (which become structs), enums, and so forth, and some of these entities can contain deprecation options (i.e., [deprecated = true]).
We map the .proto deprecation option to @available(*, deprecated) in Swift, but this causes problems within the generated code itself; if the generated serialization/parsing code touches a deprecated property in order to write/read it, that code produces a warning.
We can cheat by creating shadow properties (e.g., private underscored stored properties) and make the public one a simple computed getter/setter for it, but the same kind of cheat for enums, enum cases, and structs is less obvious.
It's desirable to have the deprecation warnings for outside clients of the code, but this also prevents the generated code itself from compiling cleanly. Would it make sense to have the compiler omit these warnings when the reference is to the deprecated entity is within the same compilation unit (or even module?), or provide a directive that lets us selectively disable them within a code region? (My argument would be that "deprecated" is a statement made about the public/open parts of an API to external users, and that it shouldn't affect internal usage.)
(Does this deserve a Swift Evolution proposal?)