Does anybody have any opinions on this? The Swift protobuf project would benefit from this; as it is today, we can't generate deprecation annotations for fields because it will produce warning noise from the compiler when the serialization code references those properties. (In the protobuf case, "deprecated" means that users shouldn't use them, but they still need to be encoded/decoded.)

I have a version working locally where references to deprecated declarations in the same file do not emit warnings:

master...allevato:omit-deprecation-same-file

If this is something that the Swift team is interested in allowing, I'm happy to do all the leg work of implementation and writing a Swift evolution proposal. Please let me know!

I think this is risky. People like to use deprecation warnings within their own code to help migrate off of certain APIs, and doing this across the whole module would break that use case. I could see it maybe working within a file.

The other thing people bring up is some kind of "deprecated" block, in which no deprecation warnings are issued, but that seems to conflate deprecations from this module with any deprecations from other modules.

It probably is worth bringing this up on swift-evolution.

Comment by David Owens (JIRA)

At the very least, the deprecation warning should not pop for usages within the type that declares it. That's the point of it being deprecated, so others know not to use it, but that type is still required to do so. Adds noise to the build output in tracking down real issues.

Example:

public struct MyType {
    public init(path: String? = nil, uri: DocumentUri? = nil) {
        self.path = path   /// warning: `path` is deprecated: The `uri` member should be used instead.
        self.uri = uri
    }

    @available(*, deprecated:3.0, message: "The `uri` member should be used instead.")
    public var path: String? = nil
    public var uri: DocumentUri? = nil
}

Gee thanks for that warning, I know! 🙂