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

[Dany St-Amant]

One potential pitfall of auto-disabling the warning for various scopes, especially the file one, is that one can by mistake add a new unintended reference. Even though it require extra change when deprecating, should there be instead a way to tag the "authorized" use.

@useDeprecated(self.phoneNumber) = phoneNumber

Not sure if something like that is possible, though it could make the code ugly, and may goes against the unwritten rule that some have: do not alter the deprecated code section itself. Maybe a similar marker for the function itself:

@usingDeprecated(Phone.phoneNumber)
@available(*, deprecated, ...)
public convenience init( ... ) { ... }


Dany

> Le 5 mai 2017 à 18:15, Tony Allevato via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> 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/0b92d301/attachment.html>