[swift-evolution] Pitch: Omit deprecation warnings for same-file references
tony.allevato at gmail.com
Fri May 5 17:15:14 CDT 2017
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
> > * 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution