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

[Tony Allevato]

On Fri, May 5, 2017 at 4:00 PM Xiaodi Wu <xiaodi.wu at gmail.com> 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.
>

Normally I'd agree with this—I tend to think caring too much about access
control beyond internal/external API boundaries is a bit too fine-grained.
But...

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.
>

After seeing some of the considerations from other folks who replied in the
thread, I've come around to your suggestion that more fine-tuning is the
best approach moving forward.

The case for deprecate-externally-but-not-internally was made well (a
library has to maintain conformances to/constraints against deprecated
protocols throughout their module and wants to do so without build noise,
even if the protocols are deprecated externally). Likewise,
deprecated-everywhere as a refactoring tool can be a boon to developer
productivity. So, thanks to those who replied with those use cases—that's
the kind of feedback I was looking for. :)

Protocol buffers (and more generally, many code-generation use cases) pose
a unique kind of problem where deprecated-outside-of-the-file/scope is
valuable. Deprecate-externally isn't helpful here because of the nature of
how Swift modules and Xcode play together—until Xcode supports static
libraries with Swift code, users who want to package something like
protobufs are going to generate that code into the same module as the rest
of their app's code. This would make deprecated-externally unable to filter
out the warnings that I want to ignore inside the generated code itself.

So I'm happy to update my draft to define how this would look based on your
strawman syntax, but I imagine that it's now getting past the point of
"easy to implement by me or someone else in the Swift 4 timeframe" so I'll
put it on the back burner for the time being.



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