<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, May 6, 2017 at 9:21 PM Brent Royal-Gordon <<a href="mailto:brent@architechies.com">brent@architechies.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[Re-sending with minor edits since this didn't initially go to the list.]<br>
<br>
> On May 5, 2017, at 3:25 PM, Tony Allevato via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> 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.<br>
<br></blockquote><div><br></div><div>(Sorry that I didn't forward this myself—I was off-the-grid over the weekend.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.)<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br></blockquote><div><br></div><div>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.)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Sent from my iPad</blockquote></div></div>