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

[Tony Allevato]

On Sat, May 6, 2017 at 9:21 PM Brent Royal-Gordon <brent at architechies.com>
wrote:

> [Re-sending with minor edits since this didn't initially go to the list.]
>
> > On May 5, 2017, at 3:25 PM, Tony Allevato via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > 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.
>
>
(Sorry that I didn't forward this myself—I was off-the-grid over the
weekend.)

To be blunt: Why should we care if a deprecated symbol is slow? It's
> deprecated, so you shouldn't be using it. (And it's only the public-facing
> part of it that's slow, which you *really* shouldn't be using.)
>

Imagine you're a client of version X of a library. You see that X+1 has
been released and has some bug fixes you would benefit from, so you
upgrade. But, the library author has also deprecated some APIs you use and
done the property-shadowing trick to get around it internally. Now you
either have the choice of (1) taking a big performance penalty or (2)
migrating immediately to replace usage of the deprecated API. Depending on
release pressures and other real-world engineering factors, option 2 may
not be feasible—maybe the migration path is non-trivial—and you'd rather
just deal with some warnings until you have the opportunity to migrate
properly.

Deprecation and performance are completely unrelated concerns, so I don't
think we should be satisfied by the answer "you're not supposed to use it
so performance doesn't matter". The workaround being discussed is an action
taken by the library author to help him/herself (and not even that much of
a help, because it requires cleaning up all the internal references to
avoid deprecation warnings there) but unconditionally penalizes the clients
of that library.



>
> Besides, I have a hard time believing we couldn't detect when the getter
> is just `return otherProperty` and the setter is just `otherProperty =
> newValue` and optimize it better.
>

I totally agree it would be nice if this was optimized. I don't have a deep
enough understanding of Swift's memory management logic to know why the
behavior is what it is today. (Looking at the optimized assembly code, it
doesn't seem to actually call the getter/setter, but the underlying
alloc/retain/release calls that get generated are slightly different in
each case.)


> Sent from my iPad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170508/eb0c0409/attachment.html>