<div dir="ltr">Doug or Fariborz, can one of you comment on if you're fine with this in theory?</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 29, 2015 at 3:33 PM, Nico Weber <span dir="ltr"><<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Ping.<div><br></div><div>Another way to think about this warning is that it effectively ignores declarations where the introduced version is higher than the deployment version.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 8, 2015 at 6:14 PM, Nico Weber <span dir="ltr"><<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi,</div><div><br></div><div>the Mac OS X and iOS SDKs add new functions in new releases. Apple recommends using the newest SDK and setting the deployment target to whatever old OS version one wants to support, and only calling new functions after checking that they are available at runtime.</div><div><br></div><div>In practice, we (Chromium) get this wrong. Others who support old OS X versions get this wrong too. Hence, we (Chromium) use a very old SDK and then manually declare new functions when we want to call them – this reduces the chance of us forgetting if they are available at runtime considerably, in practice. But using an old SDK has its problems – sometimes the frameworks check which SDK an app was linked against and only then activate bug fixes, and newer Xcodes don't ship include old SDKs.</div><div><br></div><div>Ideally, we could use a new SDK but get a warning when we use a new API without a manual redeclaration – this protects us against new APIs the same way using an old SDK does without the drawbacks that this brings.</div><div><br></div><div>The attached patch is a sketch how such a warning might work. How repulsive is this idea? Are there other approaches to this problem? If the basic idea is ok: Any comments on the implementation?</div><div><br></div><div>I'm not sure who should look at this. dgregor, you wrote r128127 which looks in the same area.</div><div><br></div><div>Thanks,</div><div>Nico</div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>