[swift-evolution] Pitch: Omit deprecation warnings for same-file references

BJ Homer bjhomer at gmail.com
Fri May 5 17:09:16 CDT 2017


> On May 5, 2017, at 1:34 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> Why guess as to which of these is appropriate? Couldn't you support the current and all variants of this behavior by allowing access modifiers on 'deprecated'?
> 
> * public deprecated: warning when used from a different module, behaves as though there's a public deprecated pass-through
> 
> * internal deprecated: warning when used from a different file
> 
> * fileprivate deprecated: warning when used from a different scope
> 
> * private deprecated: synonymous with deprecated for backwards compatibility, behaves like it does today
> 
> (No need for complicated parsing; SE-25 allows a higher nominal access modifier inside a lower one without warning, so it's fine to allow 'public deprecated' to decorate a private member with no effect.)

I’m not opposed to more configurability like that. I worry it makes the feature more complicated and potentially delays the acceptance or implementation of this feature, though. If it’s easy to implement, though, then sure, I like that.

-BJ


More information about the swift-evolution mailing list