[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