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

[Tony Allevato]

On Fri, May 5, 2017 at 3:20 PM Tony Arnold <tony at thecocoabots.com> wrote:

> Hi Tony,
>
> > On 6 May 2017, at 04:12, Tony Allevato via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > These warnings are emitted for any reference to a deprecated entity,
> including those in the same file. In some cases, however, it may be
> necessary and correct to continue referring to the deprecated entity
> privately while discouraging its external use. In these scenarios, the
> warnings are superfluous and generate noise in the build logs. We propose
> eliminating these warnings for references made in the same file.
>
> If same file is the direction that the proposal is leaning toward, what’s
> stopping you from creating an internal (or private) implementation that’s
> not deprecated. You could then call that via the public, deprecated
> method/property?
>

Hi Tony, this is called out in the proposal :) In addition to the fact that
it requires writing boilerplate code manually and updating all references
to the deprecated property in type's implementation, there are performance
implications as well due to the change in memory management behavior. In
the example presented in the proposal:

Behaviorally, these are the same. However, the generated code is different
because the memory management semantics change due to the passthrough
property. With full optimizations on, useDirectHolder executes in 1.360 sec
while useIndirectHolder executes in 235.8 sec—over two orders of magnitude
slower!



> i.e.
>
> ```swift
> @available(*, deprecated, message: "use 'phoneNumbers' instead")
> public var phoneNumber: String? {
>     get {
>         return _phoneNumber
>     }
>     set {
>         _phoneNumber = newValue
>     }
> }
>
> private var _phoneNumber: String?
>
> ```
>
> Am I missing something that would prevent this from working?
>
> I can see that what you’re proposing would negate the need for the private
> backing property/method, but it seems like it’s introducing complexity for
> the few times you might need this.
>
> thanks,
>
>
> Tony
>
>
>
> ----------
> Tony Arnold
> +61 411 268 532 <+61%20411%20268%20532>
> http://thecocoabots.com/
>
> ABN: 14831833541
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170505/e057d5a9/attachment.html>