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

[Tony Allevato]

I'm inclined to agree. I'm not opposed outright to that degree of
configurability but at the same time I wonder if the complexity is
needed—it feels like it's getting close to the "fine-tuned auditing" that I
argued against during the discussions about access control.

It could also be done additively later, if a significant amount of people
using the feature found that they did need it.

On Fri, May 5, 2017 at 3:09 PM BJ Homer <bjhomer at gmail.com> wrote:

>
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170505/b7b79b43/attachment.html>