> On May 5, 2017, at 1:34 PM, Xiaodi Wu <xiaodi...@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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
