<div dir="ltr">I would prefer something like...<div><br><div> #warn(no-warning-identifier)</div><div> ...</div><div> #warn(warning-identifier)</div><div><br></div><div>..to keep the warning identifier behavior the same in code and on the command line.</div><div><br></div><div>The ability to push and pop warning modifications (set of) could also make sense.</div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Mar 8, 2016 at 10:31 AM Russ Bishop via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There are cases where I’d like to suppress a Swift compiler warning. Is there opposition to that idea from the core team or is it just something that hasn’t been looked at yet? (Forgive me if such a thing already exists and I just missed it)<br>
<br>
<br>
My initial idea pre-bikeshedding:<br>
<br>
#suppress(warning-identifier)<br>
//some code<br>
#unsuppress(warning-identifier)<br>
<br>
<br>
The most common one I encounter is the trailing-closure syntax warning which can only be fixed by redesigning the API itself. I’ve also had to silence incorrect cast warnings (that are actually correct and execute just fine) by casting to Any first which is somewhat gross.<br>
<br>
<br>
Russ<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div>