<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, May 6, 2017 at 9:21 PM Brent Royal-Gordon &lt;<a href="mailto:brent@architechies.com">brent@architechies.com</a>&gt; 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&#39;t initially go to the list.]<br>
<br>
&gt; On May 5, 2017, at 3:25 PM, Tony Allevato via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;<br>
&gt; 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&#39;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&#39;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&#39;s deprecated, so you shouldn&#39;t be using it. (And it&#39;s only the public-facing part of it that&#39;s slow, which you *really* shouldn&#39;t be using.)<br></blockquote><div><br></div><div>Imagine you&#39;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&#39;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&#39;t think we should be satisfied by the answer &quot;you&#39;re not supposed to use it so performance doesn&#39;t matter&quot;. 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&#39;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&#39;t have a deep enough understanding of Swift&#39;s memory management logic to know why the behavior is what it is today. (Looking at the optimized assembly code, it doesn&#39;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>