<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 9, 2017 at 12:34 AM, Tony Allevato via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class="gmail-"><div dir="ltr">On Fri, May 5, 2017 at 4:00 PM Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>The reason I suggest this is that the most consistent boundary with the rest of Swift is the module. I don't doubt that some may wish to deprecate features even for some subset of internal users, but it seems plainly obvious to me that the more common scenario will be deprecating for public consumption only.</div></blockquote><div><br></div></span><div>Normally I'd agree with this—I tend to think caring too much about access control beyond internal/external API boundaries is a bit too fine-grained. But...</div><span class="gmail-"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Since you're presenting scenarios in which it might make sense to have scope-based or file-based deprecation, then more fine tuning would be the answer. Without that, I'd argue the default ought to be what I call "public deprecated." The within-a-module use case should be the later addition.<br></div></blockquote><div><br></div></span><div>After seeing some of the considerations from other folks who replied in the thread, I've come around to your suggestion that more fine-tuning is the best approach moving forward.</div></div></div></blockquote></div><div class="gmail_extra"><br></div>I think that different needs for that warning suppression would arise inside the community. Some folks may want deprecated things inside a module to trigger warnings (for example in a monolithic app) while others may not.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The best option for me is stated in the "alternatives considered" section of your proposal: just adding a "suppress warnings block" like most other languages (Java, C/ObjC, even Swiftlint). That way everyone can apply to their use cases as needed and scales to every case.</div><div class="gmail_extra"><br></div><div class="gmail_extra">About the potential of abuse, in my recent experience with ObjC, we have a policy of zero warnings and we hardly ever use those suppression warnings. Of course, like with every other feature, it can be abused, but it's not difficult to keep it controlled.</div><div class="gmail_extra"><br></div><div class="gmail_extra">From my point of view this will be the only way of having reasonable defaults for not only this warning but for every other warning. Otherwise we end up in a place where the rules for each warning are so intricate that nobody understands them.</div><div class="gmail_extra"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><p style="font-family:arial,sans-serif;font-size:13px;line-height:13px;margin:12px 0px"><span style="color:rgb(51,51,51);font-family:helvetica,arial,sans-serif;line-height:1em;display:block">Víctor Pimentel</span></p><div dir="ltr" style="font-size:12.8px"><div style="font-size:12.8px"></div></div></div></div></div></div></div></div></div></div>
</div></div>