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

[Anders Ha]

The problem happened on deprecated public protocols in ReactiveSwift. Since conformance cannot be stripped until it is inaccessible, we have a bunch of deprecation warnings on conformance clauses, scattered in the codebase. Having this on a file basis is not enough in our cases, while for sure not all deprecations need such functionality.

So IMO, an opt-in annotation for external-only depreciations is enough to cover all practical cases without over-engineering or unanticipated shadowing.

Regards
Anders

> On 6 May 2017, at 07:00, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> 
> The reason I suggest this is that the most consistent boundary with the rest of Swift is the module. I don't doubt that some may wish to deprecate features even for some subset of internal users, but it seems plainly obvious to me that the more common scenario will be deprecating for public consumption only.
> 
> Since you're presenting scenarios in which it might make sense to have scope-based or file-based deprecation, then more fine tuning would be the answer. Without that, I'd argue the default ought to be what I call "public deprecated." The within-a-module use case should be the later addition.
> 
> 
>> On Fri, May 5, 2017 at 17:15 Tony Allevato <tony.allevato at gmail.com> wrote:
>> 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170506/470d1808/attachment.html>